Dog or Tail: REST or Hypermedia?

We’re a few years deep in the REST revolution, and admittedly there are a few people really producing RESTful services. But almost everyone is missing the boat on the hypermedia requirement.

I’ve been reading some really interesting posts and blogs about hypermedia (see the mca link in my blog roll), and there is a growing resistance movement coming up against REST. People are making the claim that RPC is just a natural extension of programming practice, but we’re still arguing and struggling to figure out what REST is.

My personal opinion is that as the tools to support hypermedia evolve, REST as we know it today is going to become a side discussion. That the principles of REST will be just small part of the discussion on how we deliver hypermedia. A few examples of why I think that are:

  • If hypermedia hides URIs and treats them as opaque strings, who cares how carefully they are crafted?
  • There are lots of cases where we don’t care about the caching benefits of GET, because we’re getting transient data that we can’t cache anyway. That weakens the value of strict adherence to GET.
  • There are times when we’re making requests and don’t want to burn sensitive data into a GET URI for security reasons — so a URI doesn’t get cut-and-pasted and broadcast around the web — so we use POST and put the same information in the body of the post. That also weakens the adherence to GET.
  • There are going to be times when we don’t want to use the idempotent nature of PUT, and really do want to just send (edit: POST 🙂 ) the request a single time without somebody in the middle making retries on our behalf. That weakens the value of PUT.
  • Very few of the projects I’ve worked on have implemented DELETE. Usually they update the object with an “inactive” flag, in order to preserve relational integrity. (Which I try, with little success, to explain to them is the wrong way to go about it.) That weakens the value of DELETE.
  • If you think about it, from Roy Fielding’s point of view as a Network Architect — if I can use that term — focusing on the networking model behind REST makes a lot of sense. But from an industry point of view, the real success story of the Web is HTML. Fielding’s thesis is an interesting take on the principles that helped make the web successful, with special attention to HTTP, which he was partly responsible for. But the real, understated victory story in the web is HTML — hypermedia.

    Contrast that with all the object serialization technologies that have risen and fallen. Corba, RMI, EJB, DCOM (is that right?), SOAP. Finally programmers got so frustrated with object marshaling being buried in this or that framework, that we just expose it. Today I just marshal everything to JSON with JAX-B and Jettison or Jackson, and AJAX is just an unpleasant memory.

    But the Achille’s heel of all these technology is versioning. How do you support an object serialization scheme that doesn’t break the entire API the moment you touch one of the classes in your data model? HTML has done a fantastic job of that, and I think we should be looking at that to figure out what HTML did right, and all the others did wrong.

    REST as construed by the adherents, is a good step in that direction, but after a promising start, it leaves out the most important pieces.

    I think a few years from now, we’ll look back on the whole REST movement as an example of the tail wagging the dog, and hypermedia will be what everyone wants to talk about.



    Filed under open standards, opinionizing, REST

    9 responses to “Dog or Tail: REST or Hypermedia?

    1. You make a whole lot of great points, however, what you seem to be describing as REST is the common mis-representation of REST: well designed URIs and requirement to use all HTTP verbs.
      RESTful systems should be all about hypermedia. One of my favourite quotes on the subject:
      “It is the hypermedia constraint that makes REST as a style
      greater than the sum of its constraints. It is the focal point
      and amplifier of all the constraints.” Aristotle Pagaltzis

      • roby2358

        But see, the “experts” say very clearly and definitely that REST is all about URIs and verbs. So I’m just taking them at their word. I actually think you’re right, that representation is WAY off base.

        Taking the adherents seriously, that all the nit-picky parts must be present for it to be REST, (Except hypermedia — apparently we can ignore that part as long as our URIs and verbs are right) (…I’m being sarcastic 😉 ) that vision of REST is a big set of practices, which include distributing hypermedia.

        But I’m thinking more and more that once we work out the issues with hypermedia, we’ll realize ways to exchange hypermedia is actually a way bigger nugget than what passes for REST today.

        BTW thank you for the great comment. I work in a very pretentious, contentious environment, so I really appreciate direct, simple conversations about this stuff.

      • roby2358

        EDIT: good point… I edited & qualified my use of “REST” in a couple places.

    2. You say: “If hypermedia hides URIs and treats them as opaque strings, who cares how carefully they are crafted?”

      While this is true for consumers of the REST interface, from a management and implementation point of view, carefully crafted URI schemes are very important. From a security point of view, its much easier to configure permissions on a well defined URI scheme. From an implementation POV, you can also do funky things like hiding conditional get/post/put information within the URL.

      Also, I’d like to point out that hypermedia doesn’t necessarily have to involve the media type. It encompasses the entire message body AND the entity-headers that are transmitted. Link headers (see RFC) and custom headers can play just a big of a roll in hypermedia as XML.

      • roby2358

        Again, thank you for the thoughtful reply. I appreciate the conversation!

        > “from a management and implementation point of view, carefully crafted URI schemes are very important”

        True, but those are the same considerations we worry about outside of REST. If you build an RPC interface, carefully crafted URIs are maybe more important than they are in REST. It’s just been my experience that design discussions around REST get hung up on really stupid issues that REST, by definition, intends to obscure.

        You make a good point about hypermedia being the whole response. I really think working out what hypermedia means outside of the realm of HTML is something we’re still struggling to get our arms around. I think it’s going to be interesting to see best practices emerge around what meta-information goes where.

        One of the nice, big-picture implications of the REST craze is that it’s made everyone go back and take a hard look at HTTP. That’s led to people leveraging capabilities that have been there forever, but not used as much as they could be.

    3. If your PUT isn’t idempotent then you’re breaking the contract of PUT and you shouldn’t use it. Use POST. If you need to secure your query with a POST, I don’t see how this weakens GET at all. POST doesn’t have to mean “UPDATE” or “CREATE”. Its just a sending of a message body to the server and you’re not expecting it to be idempotent. Thats it. The thing you lose by not using GET is Cache-Control semantics. Then again, you could code your client to honor these headers on POST requests.

      Personally, I don’t like to use DELETE unless the URI is really deletable. I much prefer a PUT or POST.

      Really, PUT and POST don’t have to mean UPDATE and CREATE, IMO what they mean is:
      * GET – idempotent read of the resource
      * PUT – idempotent send of representation to a resource
      * POST – non-idempotent send of representation to a resource
      * DELETE – destroy the resource

      I don’t see your point on how anything is weakened if you model your interface on top of those semantics. The point, and importance, of these methods is to provide a pre-defined, well-defined contract between the client and server. Clients and servers that will possibly not know anything about each other. Their contract becomes the HTTP specification.

      • roby2358

        Thanks for the comment!

        The proposition of REST is weakened because every time you find a loophole that gets you out of the strict constraints of the uniform interface, it becomes less and less of a uniform interface. It becomes a “somewhat uniform interface”.

        It’s the same way as in OO. Throwing 200 methods into a class doesn’t necessarily break encapsulation, but it weakens encapsulation. At some point you might as well just get rid of the class and make those 200 methods global. Likewise, with REST, the more methods that land in POST, the less worthwhile strict REST is, and you might as well just do everything RPC style over POST.

    4. Pingback: This Week in #REST – Volume 34 (Feb 9 2011 – Mar 6 2011) « This week in REST

    5. My only critique is that making things “inactive” is an action of PUT, for example: [PUT] /article/dog-or-tail/inactivate should mark an article as inactive. Only use DELETE when the resource is really delete-able. A good example of this is typically comments, which have less of a reason for the relationship to be maintained (as you say in your writing).

    Leave a Reply

    Fill in your details below or click an icon to log in: Logo

    You are commenting using your account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s