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

[Andy Allan]

> unless the `.fmt` support is a hard requirement.

Yeah, I pretty much think it's a hard requirement - or at least (as I said above) not doing anything now that makes it impossible to implement in future. I think it would be bad to have a convention on our API (using format extensions like `.xml` and `.json` that apply to some, but not all, of the endpoints.

Two other things spring to mind:

* Since the handling of such keys is currently broken, then we know that nobody is using it. This gives us flexibility to fix it properly. For example, if we say you can no longer access keys with `.` in them in the individual preference API call, that's fine since it doesn't currently work and we won't break any consumers by changing that today.
* Even if we decide to support  `.` in key names, we currently allow `#` in key names and they absolutely can't be used in a url. Requests like `GET /api/0.6/user/preferences/something#here` won't work, since `here` is not sent to the server, even using curl.

So I iterate back to the situation where we either need to implement the `url_safe` character set for keys, or we find some way of encoding the keys such that they can work in urls. This could either be as part of the path (as discussed here) or as a query parameter (as suggested by @mmd-osm , which unfortunately also doesn't support `#`).

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

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