related: http://evertpot.com/dropbox-post-api/ 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/…
JSON in URLs
31–38 of 38 posts
Re: JSON in URLs
#32 "Programming inside the url string"
http://apenwarr.ca/log/?m=201212#18Re: JSON in URLs
#33Re: JSON in URLs
#34related: http://evertpot.com/dropbox-post-api/ 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/…
PUT and PATCH on track? I'm going to have to look into that. I had no idea progress was being made there, and i thought PUT and DELETE were basically dead.. atleast, in hopes of browsers being able to use them.
I'm not sure what the reference to PUT is (its a base HTTP method) but I assume that PATCH refers to getting it added as an RFC-specified extension to HTTP/1.1.
> and i thought PUT and DELETE were basically dead.. atleast, in hopes of browsers being able to use them.
Browsers can use PUT and DELETE.
HTML Forms however, support only the post and get methods. (I don't really get why: the semantics as form methods for PUT, PATCH, and DELETE as form methods seem pretty obvious given those of GET and POST.)
Re: JSON in URLs
#35I 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"]`). 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 reformu…
It's worth pointing out, since even here in 2015 people often don't realize this, that the querystring is permitted by the standard to contain more than one value of the same type. Thus, your second example in this case could also be cards=visa&cards=mastercard.
This is particularly a problem when you've got an overly-helpful web framework in a dynamically-typed language that normally exposes querystring parameters as a string, but if more than one gets passed in, suddenly you have an array. This can cause all sorts of fun problems, including security failures, though usually just bugs.
(Even in a dynamically typed language, a web framework should either represent querystring parameters as an array at all times xor enforce a clear, stated policy of which string it accepts if it is going to pick just one, but it should definitely not just split the difference. The latter, despite in some sense being "wrong", does have the advantage of matching people's mental model, which is a useful enough thing on its own.)
This is, incidentally, a useful "Are the developers at least this tall?" test to apply to your new Web Framework o' the Week.
Re: JSON in URLs
#36What a bad article.
Re: JSON in URLs
#37Earlier quoted context omitted.
PUT and PATCH on track? I'm going to have to look into that. I had no idea progress was being made there, and i thought PUT and DELETE were basically dead.. atleast, in hopes of browsers being able to use them.
> PUT and PATCH on track? I'm not sure what the reference to PUT is (its a base HTTP method) but I assume that PATCH refers to getting it added as an RFC-specified extension to HTTP/1.1. > and i thought PUT and DELETE were basically dead.. atleast, in hopes of browsers being able to use them. Browsers can use PUT and DELETE. HTML Forms however, support only the post and get methods. (I don't really get why: the seman…
Re: JSON in URLs
#38/v1/movies?year>=2011&artist!=cage
meaning - to add more meaning to the parameters in the query string, just add a suffix to the fieldname >/v1/movies?year>=2011&artist!=cage&name=the+rock,face+off