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

[Taylor Smock]

> Also what is the point of the first commit if the second one reverts it? If you want to offer two alternatives then open two PRs don't lump them together in one PR because then if we merge it we'll add loads of useless noise to the history.

I was planning on squashing it before it got merged. I'll go ahead and do that now.

> I wasn't actually expecting us to change the behaviour! I thought you meant you were going to fix the client to not use such silly names...
The whole point was to make it easier to map an API to the appropriate API key.

While MapRoulette has a primary instance (`https://maproulette.org/api/v2`), it is possible to have other instances (for example, Company Foo could have a private instance).

While it is possible to have each service have a static api key (for example, the main MR server could use `maproulette_apikey_v2`), it isn't very scalable. Hence why I was looking at `apikey:<API URL>`. Having the API URL as part of the key makes it trivial to map API keys to their respective services, minimizing special cases (`if (api == "https://maproulette.org/api/v2"); then key = "maproulette_apikey_v2"; else if (api == "https://random.foo"); then key = "foo_random_key"; else if (...)`).

With all that said, if you are against having arbitrary keys in user preferences, would you accept a PR that validated the PUT /user/preferences endpoint to _not_ have keys that would be invalid for the /user/preferences/[KEY] endpoints?

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

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