<p></p>
<blockquote>
<p dir="auto">It seems reasonable (and good for consistency) that asking for a single preference should return a  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).</p>
</blockquote>
<p dir="auto">In this case, it sounds like the <code class="notranslate">/user/preferences/key</code> 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 <code class="notranslate">key.fmt</code> is the desired path forward.</p>
<p dir="auto">If you want to return a structured message for this specific endpoint, maybe the <code class="notranslate">Accept</code> request header would be the best way to structure the message, and this would allow users to opt-in to the change.</p>
<p dir="auto">Issues I can see with having <code class="notranslate">.fmt</code> 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?</p>
<p dir="auto">Example:</p>
<div class="highlight highlight-text-xml" dir="auto"><pre><<span class="pl-ent">osm</span> <span class="pl-e">version</span>=<span class="pl-s"><span class="pl-pds">"</span>0.6<span class="pl-pds">"</span></span> <span class="pl-e">generator</span>=<span class="pl-s"><span class="pl-pds">"</span>...<span class="pl-pds">"</span></span>>
  <<span class="pl-ent">preferences</span>>
    <<span class="pl-ent">preference</span> <span class="pl-e">k</span>=<span class="pl-s"><span class="pl-pds">"</span>gps.trace.visibility<span class="pl-pds">"</span></span> <span class="pl-e">v</span>=<span class="pl-s"><span class="pl-pds">"</span>private<span class="pl-pds">"</span></span>/>
    <<span class="pl-ent">preference</span> <span class="pl-e">k</span>=<span class="pl-s"><span class="pl-pds">"</span>gps.trace.visibility.json<span class="pl-pds">"</span></span> <span class="pl-e">v</span>=<span class="pl-s"><span class="pl-pds">"</span>identifiable<span class="pl-pds">"</span></span>/>
    <<span class="pl-ent">preference</span> <span class="pl-e">k</span>=<span class="pl-s"><span class="pl-pds">"</span>gps.trace.visibility.xml<span class="pl-pds">"</span></span> <span class="pl-e">v</span>=<span class="pl-s"><span class="pl-pds">"</span>identifiable<span class="pl-pds">"</span></span>/>
    <<span class="pl-ent">preference</span> <span class="pl-e">k</span>=<span class="pl-s"><span class="pl-pds">"</span>key.json<span class="pl-pds">"</span></span> <span class="pl-e">v</span>=<span class="pl-s"><span class="pl-pds">"</span>{\<span class="pl-pds">"</span></span>some\<span class="pl-s"><span class="pl-pds">"</span>:\<span class="pl-pds">"</span></span>json\<span class="pl-s"><span class="pl-pds">"</span>}<span class="pl-pds">"</span></span>/>
    <<span class="pl-ent">preference</span> <span class="pl-e">k</span>=<span class="pl-s"><span class="pl-pds">"</span>key<span class="pl-pds">"</span></span> <span class="pl-e">v</span>=<span class="pl-s"><span class="pl-pds">"</span>{\<span class="pl-pds">"</span></span>some\<span class="pl-s"><span class="pl-pds">"</span>:\<span class="pl-pds">"</span></span>unexpected json\<span class="pl-s"><span class="pl-pds">"</span>}<span class="pl-pds">"</span></span>/>
  </<span class="pl-ent">preferences</span>>
</<span class="pl-ent">osm</span>></pre></div>
<p dir="auto">Anyway, I'm working on adding support for response formats on that endpoint. Using <code class="notranslate">Accept</code> headers, since I don't think there are any good ways to put the format in the URL without leading to unexpected behavior.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310281511">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLOYZLHHM3YMZICC4BLWHTZ4RANCNFSM6AAAAAARZPOMC4">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLJOPT3KMPZ5EJSTWOTWHTZ4RA5CNFSM6AAAAAARZPOMC6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSODFHSO.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/pull/3787/c1310281511</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310281511",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310281511",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>