1. 16

This is a long and thorough response to REST is the new SOAP. I haven’t finished but it seems very worth the read.


  2. 2

    No more standards, no more precise specifications. Just a vague “RESTful philosophy”, prone to endless metaphysical debates, and as many ugly workarounds.

    You could follow the OData standard, or the JSON-API standard. They’re REST after all.

    When the author writes RPC, they said they follow XML-RPC or JSON-RPC, so why ignore the standards out there for REST, then blame REST?

    While I am in the REST camp (I guess). There is a certain lack of clear reference / specification. JSON API exist (but pretty sure, it will be rejected by some other REST advocate for not being the true thing).

    I think a collection of patterns and antipatterns, referenceable would help. A bit like the C++ Core Guidelines are a solution for me to point people to a place where they can find half a page of description for a problematic or good pattern of code without me handwaving a half-right explanation for the best practice.

    How do you express the diversity of error conditions, using the very limited bunch of HTTP codes?

    Now you are confusing HTTP and REST, which is common but not correct. HTTP is a transportation layer, and as such you are expected to use the HTTP status codes to portray the category of error as far as HTTP is concerned, then application specific issues become a job for your application. I wrote an article about this too.

    This always confuses me. Have these people worked with REST over other protocols? Because sometimes it sounds this ways. Phil Sturgeon makes it clear he talks about two levels of error reporting I think, one on the transport layer, and one with more information for the API consumer. It makes sense this way.

    I do have the feeling that the this response misses the point a bit (sure, it is a factual response to the statements of the blog post by Pakal de Bonchamp ). But the original blog post already missed the point by writing about what frustrates him about REST, instead of describing why he finds the workflows for writing RPC APIs as very ergonomic. Because I have the feeling that Pakal had a workflow that worked very well for him and the team. And I can imagine this to be true, if you have your own service ecosystem, technological homogenity and if you control service and client/consumer at the same time when developing (Google Protobuf anyone?). And then we could start talking about potential benefits and drawbacks of such models, and then I think we would start talking again on why REST became big, and RPC is sometimes portraied as a thing of the past.

    1. 1

      As far as PUT with the entire resource goes, on one of my projects I had the GET return a header with a hash for the resource that a client held onto. It would send that hash back on a PUT. If it was different, the client would get a 409 Conflict with the body saying { "error" : "x has been modified prior to update"} or something like that. The client can then make another updated GET request and prompt the user, showing that someone else has modified the object while they were working on it.

      This really only works for user interface updated values, and small/low volume ones at that. Otherwise you’d probably start getting into race conditions or GET/PUT hammering.

      Our service did implement a PATCH too with just the fields to be updated. It too used a header with a hash of the current object, to ensure the same thing on a PATCH, with test cases around it.