Layers and Maps API representations do not return download and OGC web service links
Closed this issue · 2 comments
When requesting either a layer or a map with the V2 API the response does not include the relevant download links nor the OGC WMS/WFS/WCS links for the resource. This is true for requests for both the list and the detail views.
This is a regression from the pre-V2 API, which had this information in the response.
In the current state a client of the API must guess these URLs.
yes, links must be resoterd for the detail endpoints. I wouldn't include them inside the list view.
We should start to differntiate the returned fields between list and detail endpoints, to make the list response lighter.
The only thing that will need more thinking are the download URLs, since they will become asynchronous endpoints.
The only direct downlod that can be kept is the link to the original file.
@afabiani I think we can proceed on this. We will adapt the download URls when it will be the time.
@giohappy IMO the OGC web services links ought to be returned directly in the list view, and also at least one download link (maybe choose a default file format for download?). I imagine that those are probably the most important properties of a layer, from the point of view of an external API client, at least a GIS client, like QGIS.
We are designing the QGIS client to show a set of layer loading controls in our list view. For this reason it would be nice to get all available service URLs from the API list response. This means we can add our layer loading controls in a dynamic fashion and only show layer loading buttons that make sense.
If the API does not return these from the list view we will not be able to know, e.g. if that layer is available also via WFS, we will need to add a static button for that - later, when the user clicks that button we may have to return an error, if the layer is in fact not available as WFS - this would lead to a poor UX IMO