Change path structure

[cportele]

During discussions at the WFS 3.0 hackathon the following new path structure was discussed by a subgroup and was supported by the participants (underlined paths are part of the core, all other in extensions):

Advantages:

• avoids naming collisions
• clearer hooks for extensions
• more compatible with some/many URI routers
• can support servers with many collections (paging of collection metadata may be specified in an extension)

[aaime]

Would it be possible to allow implementation to use a more freeform path, like in the case of GeoServer setups, /collections/topp/states for example? Right now I'm mapping it to /topp__states to avoid having a ":" in the path, but it's ugly and potentially error prone.
The location of where each collection is could be provided in the contents document.

[pvretano]

Andrea's comment makes me think that should let the server define the path to each collection via hypermedia control (as was done with WFS 2.X in the capabilities document). So, the landing page will have all the usual links, /api, /conformance, etc. BUT there will be no /collections path. Instead, the landing page will contain hypermedia controls with "rel=collection" with the link(s) to each collection. Resolving that link will, as it does now, get you the metadata about the collection.
I have partially implemented this in my server to illustrate the point: http://www.pvretano.com/cubewerx/cubeserv/default/wfs/3.0.0/foundation?f=json
I have intentionally replaced the "collections" path element with "pathElement01/pathElement02" to emphasize the fact that the server can choose its own path to each collection. These links will not "actually" work right now since I only did a mockup in my server. Extending this idea further, similar hypermedia controls would be used to get to the features themselves, to get to the schema of the collection, to get to a map, etc. In other words navigation is hypermedia driven rather than by predefined paths. Too radical? Not sure if this breaks tools like swagger or not.

[lieberjosh]

Peter, There has been this idea that “purer REST” should be independent of any URL structure. It sounds as if flexibility of choosing URL’s is a good thing, but it does comes at a cost and due to a misconception. The misconception is that URL paths somehow must reflect a file structure or other internal operation of a server. With re-writing, re-direction and other modern server capabilities, this does not need to be true. The cost is that any semantic content of the URL is then lost, hidden away in the details of the hypermedia controls. This is fine when the server is supplying the application as well as the service, but it isn’t really consistent with independence of services from applications. If collection paths are omitted, then in order to provide something predictable that app developers can rely on, I suspect that WFS implementations will just end up with a consistent informal URL structure that isn’t maintained in the specification. It certainly can coexist with rel links in either hypermedia or headers (or both). One possibility, I suppose, would be to make defined /collections paths another extension, in case there is another good argument for not specifying canonical collection URL’s —Josh

…

On Mar 18, 2018, at 6:07 PM, Panagiotis (Peter) A. Vretanos ***@***.***> wrote: Andrea's comment makes me think that should let the server define the path to each collection via hypermedia control (as was done with WFS 2.X in the capabilities document). So, the landing page will have all the usual links, /api, /conformance, etc. BUT there will be no /collections path. Instead, the landing page will contain hypermedia controls with "rel=collection" with the link(s) to each collection. Resolving that link will, as it does now, get you the metadata about the collection. I have partially implemented this in my server to illustrate the point: http://www.pvretano.com/cubewerx/cubeserv/default/wfs/3.0.0/foundation?f=json <http://www.pvretano.com/cubewerx/cubeserv/default/wfs/3.0.0/foundation?f=json> I have intentionally replaced the "collections" path element with "pathElement01/pathElement02" to emphasize the fact that the server can choose its own path to each collection. These links will not "actually" work right now since I only did a mockup in my server. Extending this idea further, similar hypermedia controls would be used to get to the features themselves, to get to the schema of the collection, to get to a map, etc. In other words navigation is hypermedia driven rather than by predefined paths. Too radical? Not sure if this breaks tools like swagger or not. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#64 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AExWhulzmC80I8589p6eDwdiOtoenjPEks5tftqVgaJpZM4Sfl7b>.