[Someone1234]

Even this article's final conclusion is that this is a bad idea.

Data within the URL also has a number of other issues including:

- 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.

- 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).

- Maximum length

- 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.

- 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.

[fizzbatter]

For your two User points, both revolve around "Users" having access to these APIs, however the article argued that these should be deeper APIs. Not for human consumption, right? I feel like that was part of the (vague) point - Params give a URL human-usability. To go beyond that and to get more power out of a URL, they (vaguely) propose JSON as a non-human friendly format.

So for these deeper APIs, how many humans are accessing these?

And, most importantly, i don't believe the article was arguing against POST (in fact, it doesn't mention POST.. once). I believe the argument was for times when you are already using URLs to convey data, such as in a search query, that JSON might be a useful alternative to plain HTTP Params.

No?