You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am wondering if there is anything in the API standard that prevents offering the same feature (with the same ID) through several collections simultaneously. This basically means using collections as 'tags' rather than 'folders'.
The use case is to have several collections that are more and more specific, for example:
A collection with all surface water bodies
A collection with only waterways
A collection with only rivers
A collection with only lakes
etc.
Thus a river feature would be present in collections 1, 2 and 3.
The text was updated successfully, but these errors were encountered:
what you describe is perfectly fine. It would still be three features at the API level, each has a different URI. That said, you can have a convention to express that the features are the same. One approach could be to include a link with rel=canonical in each representation to the canonical URI of the feature (which may or may not be an URI of the API).
Thanks @cportele.
I definitely like the canonical link idea.
In fact, what I had in mind was to use the canonical URI as the self link, even though the feature can also be accessed through its collection URI. Do you see any issue with this?
I am wondering if there is anything in the API standard that prevents offering the same feature (with the same ID) through several collections simultaneously. This basically means using collections as 'tags' rather than 'folders'.
The use case is to have several collections that are more and more specific, for example:
Thus a river feature would be present in collections 1, 2 and 3.
The text was updated successfully, but these errors were encountered: