lesscode.org


“High” REST  

By Robert Sayre under Theory on 19. March 2006

I’d like to follow up Ryan’s post with a quick note on what they call high REST. The definition seems to be using GET/POST/PUT/DELETE. Those are the four significant methods in RFC2616, but every other version of HTTP has contained additional methods, and there are no widely deployed applications that operate that way. WebDAV is a bad example, since it doesn’t use POST, and defines many additional methods. LOCK, COPY, MOVE, and other methods are required to make it a useful protocol. The Atom protocol uses only those four methods, but it hasn’t seen wide deployment (though it may).

This reality sort of pokes a hole in the argument that “high REST” standardizes what is already known to work. That doesn’t mean it won’t work, but GET/POST/PUT/DELETE advocates who claim they are pointing out the obvious are actually making a religious argument, and that poor thesis is playing the role of C-3PO in the Ewok village. It’s unproven technology, and it should be viewed with healthy skepticism.

11 Responses to ““High” REST”

  1. Aristotle Pagaltzis:

    The question is, is it unproven on an axis that really matters?

    comment at 20. March 2006

  2. Robert Sayre:

    I’m not sure what your point is. I showed that the definition of “high” rest has no basis in reality. so… you make the call!

    comment at 20. March 2006

  3. Aristotle Pagaltzis:

    If Mark is right, then “high” REST is really just an extension of POST vs GET (already proven) to POST vs all-else; that is to say, the proof is not entirely, but very nearly complete.

    comment at 21. March 2006

  4. Phil Wilson:

    Given that the APP isn’t finished off etc. isn’t saying “The Atom protocol … hasn’t seen wide deployment” a bit of a straw man?

    comment at 21. March 2006

  5. Robert Sayre:

    The first public implementation I did was in September of 2004. It worked with public endpoints from Blogger and Typepad.

    comment at 21. March 2006

  6. Useful and Useless REST:

    […] I’ll use my first post here to repeat the ideas from Bill’s post… […]

    pingback at 22. March 2006

  7. Phil Wilson:

    Unless you’re suggesting everyone implement their own versions of the APP based on an incomplete spec (over a number of years so the implementations would not be interoperable), I’m not sure what the example of your mobile Atom client proves.

    In fact, if you were being picky, you could say that no-one has implemented the Atom API at all.

    comment at 22. March 2006

  8. Robert Sayre:

    Phil: the AtomAPI was promoted in the same way that Atom 0.3 was. But, really, this is just politics and misses the point.

    comment at 22. March 2006

  9. Phil Wilson:

    Yeah I know, I was just feeling picky. Sorry about that.

    comment at 11. April 2006

  10. Chopped:

    Yeah, but if you really want to look at “high” REST”, you’ll first have to remove the bongwater from under your eyelids.
    This will help you perpetuate a much more clear image of REST and once you have done that, “high” has already be determined. Beyond this, I see no reason to split ATOMs.

    comment at 09. May 2006

  11. Brandon Smith » REST vs. WSDL:

    […] High REST: I also call this “Unicorn REST” because, in the words of Don Ferguson, this type is a little bit more common than unicorns. This is REST as laid out by Roy Fielding. It makes use of all the HTTP verbs and has a completely stateless server. Status codes are these developers best friends. […]

    pingback at 31. July 2006