1. 7
  1.  

  2. 3

    Regarding these “problems”:

    1) Yes, REST is a convention, not a specification. This isn’t a problem, per se, though the lack of specification does create some problems- not ones mentioned in this article, though.
    2) Yes, there are lots of poorly behaved HTTP clients and servers. You can steer around the edge cases though. I have not seen any widely used software that doesn’t support things like PUT or DELETE (PATCH is the one that’s unreliable)
    3) This depends on what your API is. 99% of applications depend on basic CRUD operations for most of what they do. REST is perfect for that.
    4) Each request should represent a complete transaction. Design your resources appropriately. This simplifies the debugging and diagnosing
    5) Again, your basic operations are CRUD- all we’re doing is mapping the native verbs to HTTP verbs, and thus- no, it would be pretty easy to port this to any other CRUD-based architecture.

    There are real issues with REST- a lack of federation, a lack of discovery, a lack of validation, etc. The fact that REST is a basic CRUD API and isn’t suitable for all tasks shouldn’t be considered a mark against it.

    1. 3

      99% of applications depend on basic CRUD operations for most of what they do.

      Perhaps this is the source of the disconnect between REST fans and those of us who find it frustrating. I can’t think of a single application I’ve worked on (and they have all had/used HTTP APIs) that is primarily CRUD operations.

      1. 1

        Think about applications you use- like Lobste.rs, for example. CRUD. Any CMS, CRUD. Storefronts, CRUD. Social networks, CRUD for 90% of what they do (and message passing for others, which can sometimes be modeled as CRUD, but that’s often a leaky abstraction).

    2. 2

      I’m not sure what the point of this article is, since it’s really debating “What-most-people-call-RESTful APIs” rather than what Roy discussed in his dissertation (did the author read Chapter 5?), because nowhere was “distributed hypermedia” mentioned, despite the fact that it’s mentioned frequently by Roy. Whether or not Hypermedia APIs themselves are a “big lie”, this article is about “lowest common denominator HTTP APIs using JSON”. It makes the argument moot if they’re not going to even use Roy’s definition. If they’re going to use the “common law” definition of REST, then bringing in Roy’s dissertation seems like a distraction.

      1. 1

        Strange tone in the article. Author sounds like he’s advocating a JSON-based RPC approach, but it’s a bit of a weird mix of concerns. Looks a lot like SOAP to me. Personally, I’ve found REST to be an useful and generative architectural style.

        1. 1

          I’m also leery of any argument that begins “facebook’s…”

          Facebook last I heard had way more than 300 engineers. So whenever you hear “facebook…” you should mentally say “If you have way more than 300 engineers on board, you can….”

        2. 1

          Since the focus through both articles seems to be on REST as a SPA API (not REST as an service-to-service communication API) I find it strange that the author waits until the closing thoughts of the second article to make a sideways glance at GraphQL (by mentioning Relay). Perhaps the timing of the article wasn’t right to address that topic yet, but I feel it would be an important part of the conversation today.

          1. 1

            I like the idea of using a REST(ful?) API for reading data and a RPC API for changing data. I don’t usually work with plain CRUD apps, so having functions gives the API better semantics.