1. 18

Title is hackneyed, but the points are valid.

  1.  

  2. 10

    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.

    1. 6

      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.

      1. 6

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

        • pipe curl output to python -m json.tool, jq, etc
        • view request/response in chrome developer tools and click the little {} pretty printer thing
        • copy and paste output into some web json formatter

        With the current trend of single-page-webapps coupled with the fact that json is a first class citizen to javascript, and javascript is the de facto language of the web (oh how I wish it was lua!), means that json ends up being extremely pervasive. Many frontend devs I know make frequent use of the legibility of json on-the-wire while debugging weird issues.

        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[1], protobufs, thrift, maybe even msgpack if you desire something “jsonish”.

        [1]: I have used this. Worked well.

        1. 1

          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.

          1. 7

            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

            1. 1

              IE9 and possibly 10 are not supporting Accept-Type headers properly, so in general it’s better to use a format query parameter.

          2. 1

            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.

        2. 2

          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.

          1. 2

            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.

            1. 2

              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.

              1. 4

                Fielding specifically said that he derived REST after the fact.

                Calling it pseudo-RPC kind of misses the point. Is RPC pseudo-REST?

          2. 14

            I don’t find this article to be particularly convincing, but I’m also just so, so, so sick of arguing about REST. So I think I’m just gonna leave it at that.

            1. 10

              BTW, I highly recommend Steve’s Nobody understands REST or HTTP post back from 2011. Especially to the author of this article.

              1. 3

                Thanks. I’m hoping to finish up DHAs soon, I just got really, really burned out on this topic.

            2. 8

              Prediction: the title will get more discussion than the actual article.

              Ultimately, I think this boils down to three basic points:

              1. HTTP is a terrible protocol. It evolved haphazardly, is misfeatured for the web it’s intended for, and is insufficiently-featured to be a decent API protocol.
              2. People are terrible at picking the right protocol. Human-readability should only be a concern if human-readability is a concern, and it must be understood to work against every other technical property of a protocol.
              3. REST is a very poorly-defined term, so discussions about it very easily decay into semantics and untrue scotsmen.
              1. 4

                Human-readability should only be a concern if human-readability is a concern, and it must be understood to work against every other technical property of a protocol.

                This is a really great point.

                1. 4

                  REST is a very poorly-defined term, so discussions about it very easily decay into semantics and untrue scotsmen.

                  The dissertation defines it fairly well, it’s the last decade of blog posts that make it difficult to discuss.

                  1. 2

                    The dissertation tries to generalize from a single example; naturally it gets some aspects wrong. Its definition is precise, but that doesn’t make it accurate.

                2. 4

                  Some points are valid, some might be valid, but have no supporting information, e.g.

                  most bizarre: stateful POST on /searches with criteria modeled with JSON-like structure, returning URL to search results (/searches/25), which can later be queried

                  “most bizarre”? OK, why? Might be bizarre for some cases, might not. Can’t tell.

                  Otherwise this is fairly rant-y, basically pointing out places where REST might not be useful, or where the “commonplace” implementations are poor, but what else is new?

                  I agree that “building all these levels of abstractions we forgot that web is really asynchronous”, so let’s stop doing that. Stuffing those requests/responses in a queue doesn’t always solve the problem (it might, or it might just move the problem somewhere else).

                  But, whatever.

                  1. 3

                    Title is hackneyed

                    Yes, for why please see: “Considered Harmful” Essays Considered Harmful

                    Odd the author linked to this themselves and yet still chose to use this title.

                    1. 2

                      I had a bit of a wild swing at the query formatting problem with Tranquil APIs … feedback welcome!

                      1. 2

                        “Considered Harmful” Essays Considered Harmful http://meyerweb.com/eric/comment/chech.html

                        1. 1

                          The author reveals a fundamental misunderstanding of REST in the opening sentence, calling it an IPC protocol. It is actually a counterpoint to IPC.

                          1. 4

                            How is rest not IPC? It’s a counterpoint to RPC perhaps, but it sure looks like processes communicating to me.

                            1. 1

                              Ah, I conflated IPC and RPC. Oops.

                          2. -1

                            Diagnosis: author is smoking crack.

                            Not to mention Swagger, the de facto standard for REST documentation,

                            No, you idiot. RFC 6838 is the de facto standard for REST documentation. Swagger is an alternative to REST, as you said yourself.

                            RESTful web services are CRUD-oriented, rather than business- or transaction-oriented.

                            No, you idiot. You’re right that if you confuse REST with CRUD you are going to have problems.

                            Countless times we had to carefully map business terms into simple create/update/delete actions.

                            Yes, you idiot. If you want to get the benefits of REST you have to carefully map your protocol into things where recovery from failed connections is possible. If you don’t care just use RPC (whether HTTP POST or XML-RPC or Sun RPC with XDR or whatever) and then suffer the problems described in A Note on Distributed Computing twenty fucking years ago. Or invent your own architectural style to solve them. But don’t come whining to Roy about how programming distributed systems is hard. We know it’s fucking hard. We invented REST to make it tractable.

                            The de facto standard format for REST is JSON.

                            No, you blithering idiot. The de facto standard media-type for REST is HTML or possibly JS, although Flash put up a good fight for a while there. Binary media types work fine with REST. REST was invented in 1996–9 and formalized in 2000. JSON was designed in 2002. What the fuck even is wrong with you?

                            1. 18

                              Diagnosis: author is smoking crack
                              No, you idiot.
                              No, you idiot.
                              Yes, you idiot.
                              No, you blithering idiot.

                              I would have downvoted this, but there is no downvote option for “hostile tone for no apparent reason”.

                              1. 3

                                Heh, no kidding. That’s been bothering me, too; “troll” is up to the voter to define, but at least is available if one feels it fits. I generally don’t downvote comments anyway though, it’s not often the productive way to continue.

                                1. 2

                                  Downvote for troll and move on

                                  1. 3

                                    The problem is that I clearly wasn’t trolling — you can clearly see that what I said is not only sincere but also correct. It’s tempting to write off the original article as a troll (especially given its flamebait title!), but there’s really no indication that the original author is anything but sincerely and profoundly ignorant.

                                    1. 1

                                      The article’s author is not profoundly ignorant. The fact of the matter is that “REST” is very inconsistent in practice (the only really universal-seeming aspect being that it goes over HTTP), and so reasonable people can disagree over what it actually means. Neither you nor the article’s author are strictly wrong.

                                      1. 2

                                        Reasonable people cannot disagree over what REST actually means. Roy Fielding coined the term to describe the architectural style embodied in the HTTP/1.1 standard, which he also wrote, and wrote an entire chapter in his dissertation about what it means. That’s the origin of the term, and that was only 15 years ago. People who use “REST” to promote their random poorly-thought-out hacks that happen to use HTTP as a transport are cynical charlatans, attempting to free-ride on the goodwill accrued by the REST architectural style.

                                2. 12

                                  Your comment would be better without repeatedly calling the author an idiot.

                                  1. 10

                                    You are correct. I am afraid I am turning into Erik Naggum. :(

                                  2. 7

                                    If you want to get the benefits of REST you have to carefully map your protocol into things where recovery from failed connections is possible. If you don’t care just use RPC […] and then suffer the problems described in A Note on Distributed Computing

                                    Extracting this bit (which gets to the core of why REST exists) in the hope that people will look past the tone.

                                    1. 4

                                      I for one am absolutely fine with minor abuse, especially if the person doling it out has done their research (as is case here).

                                      1. 4

                                        I’m very surprised. Are you accustomed to working in a hostile environment? It’s easy to ignore these things once you’re used to them, but taking a step back and looking at it the GP is really very unpleasant, and with very little value in the unpleasantness.

                                        1. 5

                                          Furthermore my anger is misplaced: I should be directing it at the charlatans who claim that their JSON-CRUD systems are “REST”, not at the poor idiots they manage to take in.