This is a great, sane feature.
Although, if your site has code injected into it, you might have some other problems that are bigger than this.
The author’s top complaint is that JSON is not a binary format and is not compressed, but I think he is forgetting that most web servers Gzip responses on the fly. That layer of compression is going to get you eighty per cent of the performance you need in that area.
Also, JSON-LD is introducing standards to make responses follow a schema not to mention other works like JSON API (which is now 1.0).
I don’t think this author is very well grounded in his arguments. REST is not a one size fits all but it does generally work in most cases.
Yeah, JSON can be gzip’d, but that consumes CPU. And for what? Readability that requires exactly as much tool intervention as, say, thrift or protobufs? I challenge anyone to pick out the structure of a machine generated, unformatted JSON string without invoking a tool – thus, obviating the putative “human readable” advantage.
You can take the output of a response and easily format it in many ways though. The ubiquity of such tooling can not be discounted. Some examples (certainly not exhaustive):
python -m json.tool
If you are talking about a “pure” http api that interacts with something like mobile devices, customized tooling, or backend only systems, then there are indeed many seemingly superior encoding choices: capnproto, protobufs, thrift, maybe even msgpack if you desire something “jsonish”.
: I have used this. Worked well.
REST supports different formats too so the API can respond to /api/user?format=json and /api/user?format=msgpack. There’s no need to marry a given format.
REST supports is kind of an odd thing to say. Features are added by dev teams, and of course require support and testing. What you say is true though. You can indeed support many different return types. It is easier with self describing formats (like returning xml, json, or msgpack as the client requests). It is harder to include types like protobufs, capnproto, thrift, etc, as it requires more work, maintenance, and testing.
Aside: I have occasionally been told that using a format query param is poor form, and that http accept headers should be introspected instead, with a clearly defined default/fallback. Others say arguments are fine. Still others say to append the request with “.json” or “.xml”, which I personally consider a very poor choice, but I still hear it sometimes. shrug
IE9 and possibly 10 are not supporting Accept-Type headers properly, so in general it’s better to use a format query parameter.
Just curious, why do you wish it was lua? Though I don’t mind the language, I didn’t exactly fall in love with it, mainly because of the arrays start at 1 thing, but also because it seemed a little verbose, almost like BASIC.
I have worked with jsonschema stuff and I admit to not like it very much. It is cumbersome, verbose, and hard to work with large schemas. I vastly prefer the approach taken by capnproto, protobufs, thrift, where schemas are more struct like.
I will take a look at json-ld though. Hadn’t run across it before. Seems interesting.
I dunno, it seems to me that the author’s top complaint is that HTTP methods and response codes are not nearly expressive enough for some complex systems. REST works great when you are working with things that are obviously modeled as resources. Every time I build a REST system I end up with a few “resources” that are really just endpoints for RPCs.
Lots of business actions touch multiple resources equally, and can’t simply be expressed as an HTTP verb applied to one of those resources.
I feel like the Fielding paper is really just an elaborate if fantastically convincing retcon. Nothing about HTTP seems particularly well-designed to me, and shoe-horning it into a pseudo-RPC role just feels like ex post facto reasoning.
Fielding specifically said that he derived REST after the fact.
Calling it pseudo-RPC kind of misses the point. Is RPC pseudo-REST?