A little confused. The author is arguing _against_ JSON in URLs, right?<p>The piece starts as a list of complaints about hacky query parameter encoding, and has the feel of one of those "aren't these things annoying... but here's the right answer!" posts, except instead of a correct answer we get a discussion of how JSON is nice in some cases but we shouldn't use it in URLs, except maybe sometimes.<p>Is this a response to some post about how JSON _should_ be used in URLs? Overall, I struggled to find a coherent narrative / argument here. Perhaps something went wrong in the article's editing process.
Even this article's final conclusion is that this is a bad idea.<p>Data within the URL also has a number of other issues including:<p>- It is easier to leak (e.g. browser history, proxies, some browser extensions, etc). Very few things record HTTP POST parameters unless they're doing something evil, very many non-evil pieces of software record the full URL.<p>- Users intentionally or inadvertently re-posting data is much more likely. No browser's autocomplete re-posts HTTP POST parameters to the website, many will do so with HTTP GET parameters, which could result in a worse user experience (or in rare cases the user performing actions on your website within intending to).<p>- Maximum length<p>- The encoding/decoding step could be extremely expensive for some data. JSON itself requires a lot of decoding but depending on what you're moving it could mean almost all of the data requires it making the URL string insanely massive.<p>- Users will copy/paste these URLs to one another and the JSON will remain in all its 200+ character ugly glory. This may not be a security issue but it is a user perception issue. URLs are meant to be getting cleaner/more human readable.
A JSON like syntax that is URL query compatible sounds like a great solution to me. Rison tried this approach a couple years back: <a href="https://github.com/Nanonid/rison" rel="nofollow">https://github.com/Nanonid/rison</a>
I designed something similar while writing scoutcamp (an express.js competitor). I made it so that it could parse both normal queries (eg, `?age=12&cards=visa&cards=mastercard`) and JSON (eg, `?age=12&cards=["visa","mastercard"]`).<p>I'd argue that design is easier to read and allows graceful degradation: someone using an API with fields `age` and `cards` can rely on the traditional way to work. They can easily reformulate their query when more complex structures are required. Yet Ajax scripts can use a simple shim to make XHR calls that send arbitrary JSON data.<p><a href="https://github.com/espadrine/sc/blob/master/lib/camp.js#L82" rel="nofollow">https://github.com/espadrine/sc/blob/master/lib/camp.js#L82</a>
related: <a href="http://evertpot.com/dropbox-post-api/" rel="nofollow">http://evertpot.com/dropbox-post-api/</a><p>Basically everything about the status quo is messed up.<p>JSON into parameters: bad.<p>JSON into request body: undefined with the GET method.<p>JSON into request body with POST: great, but we're not actually mutating anything, so it's bad practice and won't be cached by varnish/nginx + a barrage of other problems.<p>I really wish someone would take up on <a href="http://www.ietf.org/rfc/rfc3253" rel="nofollow">http://www.ietf.org/rfc/rfc3253</a> - like REPORT as an analogue to GET, just with a JSON request body. Hey, we as a community finally managed to get PUT and PATCH on track, why not this one?
When I pass around any parameters in GET or POST parameters I wrap them in base64. That makes a <i>lot</i> of escaping bugs go away (and adds a bit of "security by obscurity", as well as true security when combining the query with a random number, a sha256 hash of the parameters and a serverside secret).
May I recommend the following blog post:<p><a href="http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding" rel="nofollow">http://blog.lunatech.com/2009/02/03/what-every-web-developer...</a><p>and the HN discussion of that post:<p><a href="https://news.ycombinator.com/item?id=5930494" rel="nofollow">https://news.ycombinator.com/item?id=5930494</a><p>I used JSON in the URL to preserve the state of a report across reloads. I kind of regret it, because it wouldn't have been that much work to maintain a URL with normal query args. I think I had in mind that JSON would better handle things like the collapse/expand state of nested groups (a tree, essentially), but mostly I was just lazy, considering that I never got that far.
We actually do something similar to this to make our application state (within limits) be reflected by the url and support navigation — both good things. The urls are horrible though and we're considering simply storing the state in a service and giving it a serial number (but this has its own issues).<p>I was hoping the article was proposing a better way of encoding Json as urls, e.g. using the characters that are allowed in place of curly braces etc and doing simple translation. E.g {"foo":"bar","baz":[]} becomes foo=bar&baz=&&
JSON in URL: /log?%7B%22a%22:%22b%22,%22c%22:4%7D<p>You are debugging and need to quickly identify the values you are passing to the API. Better have a JSON parser handy.
We have used this syntax for url filters, works surpricingly well:<p>/v1/movies?year>=2011&artist!=cage<p>meaning - to add more meaning to the parameters in the query string, just add a suffix to the fieldname ><!~ etc. Before using the query, just filter them out. To add an array of options, just add the same field twice or use comma in the value:<p>/v1/movies?year>=2011&artist!=cage&name=the+rock,face+off
I'm all for (ab)using specs whenever convenient, but this is just such a bad idea.<p>You will rarely actually use query args (ie ?x=y&foo=1) with a true REST API anyway. Use your resource path and avoid query args except for idempotent GET operations. If you have complex data, just put it in a request body as JSON. Don't put that crap in a query arg. That's not what it's for.
Why JSON in the url as query parameters?<p>What benefit do you give you API caller?<p>What benefits do you give browser / caller caching for GET?<p>It really feels like they needed to get some content out for some reason, and just found some post in some internal dropbox wiki and posted it. Maybe they posted a draft by accident? I dont know...
I noticed this on the official results page of the recent Parliamentary Elections in Greece. It uses JSON in the hash.<p><a href="http://ekloges.ypes.gr/current/v/public/index.html?lang=en" rel="nofollow">http://ekloges.ypes.gr/current/v/public/index.html?lang=en</a>
A simple solution that can often work is to store the JSON in a database, assign a number to it, and use that number in the URL instead of the JSON. One could even add a cryptographical checksum (e.g., hash with secret salt) to make it a bit safer.
Reminds me of one of my favourite @apenwarr articles.<p><pre><code> "Programming inside the url string"
http://apenwarr.ca/log/?m=201212#18</code></pre>