Open jyutzler opened 2 months ago
The issue is not clear to me.
If a client does not know what it wants, the flow is as follows:
{baseResource}/styles
rel
"stylesheet" and a type
that the client can handle.href
If the client knows the style URI or id, it can directly GET {baseResource}/styles/{styleId}
with an Accept
header that identifies the style encodings / media types supported by the client and their priorities. The client will receive the best match or a 406
response.
There is, of course, the issue that none of the style encodings have registered a media type with IANA. The approach has been to use media types in the vnd
branch (that theoretically OGC could also register) and include a media type definition for style encodings that are normatively referenced.
It looks like I got a few things wrong when reviewing the API.
.../style/{styleId}
does in fact return the style based on the "Content-Type" header (I got this wrong; it is Req 5B). Your response says "Accept" header but since this is not in the document, I assume your reply was incorrect..../style/{styleId}/metadata
which presumably matches the "describedBy" rel in the style descriptor (I got this wrong, this is Req 6).Given this, I make the following recommendations:
.../style/{styleId}/metadata
, which is currently specified in Requirement 7B .../style/{styleId}/metadata
, why not schema or preview?
Clients should not be forced to perform multiple GET requests if they know what they want. The current behavior is:
{baseResource}/styles/{styleId}
This is annoying. Condense this into one step by adding GET
{baseResource}/styles/{styleId}/stylesheet?type=...
or GET{baseResource}/styles/{styleId}/{type}
.We can also add endpoints for the singleton _rel_s:
{baseResource}/styles/{styleId}/schema
{baseResource}/styles/{styleId}/describedBy
{baseResource}/styles/{styleId}/preview
I want to keep the existing behavior for discoverability purposes as the client will not necessarily know which type is available.