JSON in URLs • Hacker News Board

Re: JSON in URLs

#21

Post by kej » Wed, Mar 25, 2015, 9:29 PM UTC

Someone1234 wrote: post #13

mschuster91 wrote: post #4

When I pass around any parameters in GET or POST parameters I wrap them in base64. That makes a lot 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).

Not that this matters to your overall point, but base64 isn't actually a valid format to use in a parameter as a base64 string can legally contain: '+', '/' and '=' which would be interpreted and corrupt the data. In the .Net world you'll want to use something like HttpServerUtility.UrlTokenEncode()/UrlTokenDecode() since it gives you a base64-like string with '+', '/' and '=' replaced or removed.

You can use base 64 with a URL-safe alphabet, as specified in RFC 4648: http://tools.ietf.org/html/rfc4648#page-7

Re: JSON in URLs

#22

Post by jonaf » Wed, Mar 25, 2015, 9:29 PM UTC

namesbc wrote: post #14

A JSON like syntax that is URL query compatible sounds like a great solution to me. Rison tried this approach a couple years back: https://github.com/Nanonid/rison

Rison (specifically O-RSON) is a great solution to this problem. We use it in production and have done so for a couple years now, and it's served us very well to address this problem.

Re: JSON in URLs

#23

Post by Tloewald » Wed, Mar 25, 2015, 9:44 PM UTC

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

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=&&

Re: JSON in URLs

#24

Post by zwily » Wed, Mar 25, 2015, 9:46 PM UTC

Tloewald wrote: post #23

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). I was hoping the article was proposing a better way of encoding Json as urls, e.g. using the characters that are all…

Semi-related - there is rison: https://github.com/Nanonid/rison

Re: JSON in URLs

#25

Post by pdknsk » Wed, Mar 25, 2015, 9:51 PM UTC

I noticed this on the official results page of the recent Parliamentary Elections in Greece. It uses JSON in the hash.

http://ekloges.ypes.gr/current/v/public/index.html?lang=en

Re: JSON in URLs

#26

Post by endymi0n » Wed, Mar 25, 2015, 10:01 PM UTC

Basically everything about the status quo is messed up.

JSON into parameters: bad.

JSON into request body: undefined with the GET method.

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.

I really wish someone would take up on http://www.ietf.org/rfc/rfc3253 - 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?

Re: JSON in URLs

#27

Post by asabil » Wed, Mar 25, 2015, 10:07 PM UTC

Once you get there, maybe base64url binary blobs are way more efficient and quite compact.

Re: JSON in URLs

#28

Post by fizzbatter » Wed, Mar 25, 2015, 10:10 PM UTC

Someone1234 wrote: post #10

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 m…

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?

Re: JSON in URLs

#29

Post by fizzbatter » Wed, Mar 25, 2015, 10:12 PM UTC

asabil wrote: post #27

Once you get there, maybe base64url binary blobs are way more efficient and quite compact.

Agreed. I was thinking the same thing. A fast and small encoding _(whatever that encoding may be)_ would help immensely, and is far more sane than url encoded JSON, imo.

Re: JSON in URLs

#30

Post by omgitstom » Wed, Mar 25, 2015, 10:12 PM UTC

Why JSON in the url as query parameters?

What benefit do you give you API caller?

What benefits do you give browser / caller caching for GET?

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