Re: [dxwg] Use Case: Negotiation by Coordinate Reference System

If I understand it correctly, the whole `Profile` idea is to wrap all kinds of conneg things into one 'profile', correct? The problem I see comes from a developer point of view, where this can become some sort of wildcard to support anything. I think this makes it very difficult for clients to identify which options are actually supported and for servers to make clear which options are going to be implemented and to validate all these options.

As an API designer, the reason I want to support multiple options (with their own names) is to clarify documentation, automate generation of client and server libraries, etc. For example, two different ways to retreive active bugs from a collection of issues, sorted by title using an API could be modelled like this:

1. `/issues?type=bug&status=active&orderBy=title`
2. `/issues?query="WHERE type='bug' AND status='active' ORDER BY 'title'`

The latter option would work for very complex and flexible systems where you can define your own properties etc. However, it becomes almost impossible to use generic tooling to describe all possible options other than "the API supports a `query` parameter and you can put some aspect of some query language in it".

The first option, however, is very easy to document, understand, validate and implement for both clients and servers. In my opinion the same applies to content negotiation: separate request and response headers look like the first approach, where wrapping all non-existing conneg headers in one single `Profile` header looks more like the second approach.

That said, besides CRS there might be more spatial options influencing the response/request payloads, like the precision of the coordinates. This might be a reason to introduce a more generic `Accept-Geo` or `Profile-Geo` header instead of using `Accept-Crs`, but moving it all to the `Profile` header could mean there will be countless options possible using `Profile`.

By the way, the reason I've opened the discussion again is because we'd like to adhere with global standards instead of creating our own headers. However, at the moment I'm still not convinced by solving CRS negotiation using `Profile`. Just like `Accept-Language` and `Content-Language`, using `Accept-Crs` and `Content-Crs` seems to be the most practical solution for us at the moment (I believe the `X-` prefix isn't required anymore, but I don't know the RFC by heart ;-)).

-- 
GitHub Notification of comment by dvh
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/311#issuecomment-411396639 using your GitHub account

Received on Wednesday, 8 August 2018 13:01:10 UTC