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

[Taylor Smock]

> 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).

In this case, it sounds like the `/user/preferences/key` endpoint should be deprecated, since I don't think there is a way to change the current semantics without breaking current users of that endpoint, at least if `key.fmt` is the desired path forward.

If you want to return a structured message for this specific endpoint, maybe the `Accept` request header would be the best way to structure the message, and this would allow users to opt-in to the change.

Issues I can see with having `.fmt` in the URL would be where someone decides to add (maliciously perhaps), something that is a duplicate of a pre-existing key, but with the format. What behavior should be exhibited?

Example:
```xml
<osm version="0.6" generator="...">
  <preferences>
    <preference k="gps.trace.visibility" v="private"/>
    <preference k="gps.trace.visibility.json" v="identifiable"/>
    <preference k="gps.trace.visibility.xml" v="identifiable"/>
    <preference k="key.json" v="{\"some\":\"json\"}"/>
    <preference k="key" v="{\"some\":\"unexpected json\"}"/>
  </preferences>
</osm>
```

Anyway, I'm working on adding support for response formats on that endpoint. Using `Accept` headers, since I don't think there are any good ways to put the format in the URL without leading to unexpected behavior.

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

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