[openstreetmap/openstreetmap-website] Supporting multiple API versions (#2353)

Andy Allan notifications at github.com
Wed Sep 4 12:03:13 UTC 2019


>Consider for example the output of https://api.openstreetmap.org/api/0.6/map?bbox=-122.083819,37.4217991,-122.0834335,37.4222209
>Which starts with
> `<osm version="0.6"`

Right, and I would expect the output for any requests made to api/0.7 will start `<osm version="0.7">`. If a client is making requests to the api, then it would expect the response version to match the request version. If it wants a 0.6 response, it should make a request to the 0.6 endpoint.

Now if that response is saved somewhere, then it's useful to know which version of the API originally created that document, so that you know how to parse it. The version in the document is the version of the response. It's not related to some underlying abstract data model, if there is such a thing.

For example, imagine if we keep this underlying abstract data model exactly the same, but change the response format. This could be* changing tags to have "key" and "value" attributes instead of "k" and "v". Then it seems obvious that the response should be `<osm version="0.7" ... <tag key="..." value="...">`, since software will need to know the version of the response to know how to parse it. But this illustrates my point - the version in the document is tied to the **representation** of the data, not the underlying abstract data model, which hasn't changed.

So this PR follows what I expect most other people expect - that the version in the returned document matches the version of the API that requested the document.

(* purely for example; I'm not proposing this)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/2353#issuecomment-527870438
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20190904/a6cd6c9a/attachment.html>


More information about the rails-dev mailing list