[openstreetmap/openstreetmap-website] Allow `user/preferences/[KEY]` to accept arbitrary keys (PR #3787)
Taylor Smock
notifications at github.com
Wed Nov 9 21:50:39 UTC 2022
Right now, `GET /user/preferences/key` will (according to the [wiki documentation](https://wiki.openstreetmap.org/wiki/API_v0.6#Preferences_of_the_logged-in_user)) "[return] a string with that preference's value." Which makes sense.
So a `k="foo" v="{\"json\": true}"` would return `{"json": true}`, regardless of what format is requested (`GET /user/preferences/foo.xml`). The only things I can think of that could possibly change by adding a format:
* Wrapping the value, so `{"key": "foo", value: "{\"json\": true}"` or `<preference k="foo" v="{\"json\": true}"/>`, which I don't think adds any value to users. They already _know_ the key, and regardless of the response, they still have to do the appropriate action with the value. Just with more steps, and possibly assuming that there was some kind of server-side validation.
* Validating the value prior to return, although this is probably unwise since the value could be of any arbitrary format (xml, json, base64 encoded binary data), which means there would have to be format sniffers of some type.
The point being that the preference value can be anything, and the application developer is going to have to deal with it (unless it is dealt with inside the website code), so I don't think this _specific_ endpoint (`/user/preferences/key`) can realistically return anything besides the plain text value.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1309421713
You are receiving this because you are subscribed to this thread.
Message ID: <openstreetmap/openstreetmap-website/pull/3787/c1309421713 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20221109/cfd2c031/attachment-0001.htm>
More information about the rails-dev
mailing list