11–20 of 38 posts
Earlier quoted context omitted.
This is already a problem if you ever have to work with non-ASCII characters. Check out a URL to a page in the Japanese Wikipedia, for instance.
http://ja.wikipedia.org/wiki/ベーカーストリート・アンド・ウォータールー鉄道
Earlier quoted context omitted.
This is already a problem if you ever have to work with non-ASCII characters. Check out a URL to a page in the Japanese Wikipedia, for instance.
http://ja.wikipedia.org/wiki/ベーカーストリート・アンド・ウォータールー鉄道
Request URL:https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%BC%E3%82%AB%E3...
Your browser will equally pretty up the json in the url for display purposes.
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).
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.
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).
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).
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).
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.
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.
http://blog.lunatech.com/2009/02/03/what-every-web-developer...
and the HN discussion of that post:
https://news.ycombinator.com/item?id=5930494
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.