[openstreetmap/openstreetmap-website] Allow `user/preferences/[KEY]` to accept arbitrary keys (PR #3787)

[Andy Allan]

> So a `k="foo" v="{\"json\": true}"` would return `{"json": true}`, regardless of what format is requested

I think you've misunderstood my point, since I wasn't talking about encoding json into the values. In fact I wasn't discussing the values of the user preferences at all.

The point is that for our other API calls, we have a convention of returning responses in either XML or JSON, and not plain text. Furthermore, for calls that return multiple objects we return a list of objects, and for calls for individual objects we return the individual object, not just the "contents" of the object. Compare for example with nodes:

```
GET /api/0.6/nodes?nodes=123,456

<osm version="0.6" generator="...">
  <node id="123" visible="true" version="12" changeset="..."/>
  <node id="435" visible="true" version="2" changeset="..."/>
</osm>
```

```
GET /api/0.6/node/123

<osm version="0.6" generator="...">
  <node id="123" visible="true" version="12" changeset="..."/>
</osm>
```

Note that for an individual node request we return the whole node object, even though you could argue that the id is redundant and there's no need to return the object, you could just return the attributes. Now we compare with preferences:

```
GET /api/0.6/user/preferences

<osm version="0.6" generator="...">
  <preferences>
    <preference k="gps.trace.visibility" v="trackable"/>
    <preference k="MerkaartorBookmark000" v="London;..."/>
  </preferences>
</osm>
```

It seems reasonable (and good for consistency) that asking for a single preference should return a `<preference>` object, not just one of the attributes of the preference. The same thought process equally applies to JSON format requests and responses (again, this is nothing to do with the contents of the value attribute).

Now at the moment we don't provide a structured responses for individual preference requests, but the reason that I don't like this proposal is that it will prevent us from doing so in future. 

In particular, we need to be able to return structured error messages, which is a common complaint about parts of our API. We can't return error messages in a structured format without giving the developers the ability to make format-specific requests! I.e. if you want xml structured error messages then you need to be able to make XML formatted requests (e.g. request urls ending in .xml), and so if requests have a format then the non-error responses should be formatted to match. Again, this highlights why we are moving away from plain-text responses and the importance of allowing format-specific request urls.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310093797
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/3787/c1310093797 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20221110/b1b477d3/attachment.htm>