<p></p>
<blockquote>
<p dir="auto">So a <code class="notranslate">k="foo" v="{\"json\": true}"</code> would return <code class="notranslate">{"json": true}</code>, regardless of what format is requested</p>
</blockquote>
<p dir="auto">I think you've misunderstood my point, since I wasn't talking about encoding json into the values. In fact I wasn't discussing the values of the user preferences at all.</p>
<p dir="auto">The point is that for our other API calls, we have a convention of returning responses in either XML or JSON, and not plain text. Furthermore, for calls that return multiple objects we return a list of objects, and for calls for individual objects we return the individual object, not just the "contents" of the object. Compare for example with nodes:</p>
<pre class="notranslate"><code class="notranslate">GET /api/0.6/nodes?nodes=123,456

<osm version="0.6" generator="...">
  <node id="123" visible="true" version="12" changeset="..."/>
  <node id="435" visible="true" version="2" changeset="..."/>
</osm>
</code></pre>
<pre class="notranslate"><code class="notranslate">GET /api/0.6/node/123

<osm version="0.6" generator="...">
  <node id="123" visible="true" version="12" changeset="..."/>
</osm>
</code></pre>
<p dir="auto">Note that for an individual node request we return the whole node object, even though you could argue that the id is redundant and there's no need to return the object, you could just return the attributes. Now we compare with preferences:</p>
<pre class="notranslate"><code class="notranslate">GET /api/0.6/user/preferences

<osm version="0.6" generator="...">
  <preferences>
    <preference k="gps.trace.visibility" v="trackable"/>
    <preference k="MerkaartorBookmark000" v="London;..."/>
  </preferences>
</osm>
</code></pre>
<p dir="auto">It seems reasonable (and good for consistency) that asking for a single preference should return a <code class="notranslate"><preference></code> 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>
<p dir="auto">Now at the moment we don't provide a structured responses for individual preference requests, but the reason that I don't like this proposal is that it will prevent us from doing so in future.</p>
<p dir="auto">In particular, we need to be able to return structured error messages, which is a common complaint about parts of our API. We can't return error messages in a structured format without giving the developers the ability to make format-specific requests! I.e. if you want xml structured error messages then you need to be able to make XML formatted requests (e.g. request urls ending in .xml), and so if requests have a format then the non-error responses should be formatted to match. Again, this highlights why we are moving away from plain-text responses and the importance of allowing format-specific request urls.</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-1310093797">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLLMEEVVKZLPGN3TESLWHTG5ZANCNFSM6AAAAAARZPOMC4">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLL67LFT3MBVTELSNW3WHTG5ZA5CNFSM6AAAAAARZPOMC6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOCZY6K.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/c1310093797</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-1310093797",
"url": "https://github.com/openstreetmap/openstreetmap-website/pull/3787#issuecomment-1310093797",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>