Rest, I dont think I get it

Posted: March 1, 2010 in geek stuff, work

I sent this as an internal email.. but figured I would post the question as well. File this into the “I dont get it” category. Not as bad as Google Wave, but close.

So.. I hear that Rest is a panacea, but mostly because it is “Rest not SOAP”. I actually understand many of the benefits that REST is gives you:

1) I can use a simple http client to access resources, therefore it is easier to adopt.
2) I inherit alot of the WS-* enhancements from the underlieing http transport, so the frameworks are lighter weight.
3) The ability to use the service both by a client and a browser.. mashups become easy.

What I keep getting hung up on is the absence of a formal description of the interface. I see WADL, but whenever I dig into this it seems to get brushed aside as a nuisance. If i want to write typed clients, then I need to have some formal contract of what can be passed in and what is returned. This contract seems to be what alot of the cruft around SOAP is for. Is there something I am missing with this? The answer the books/articles seem to give is “who needs a formal spec, it is all URI’s”. This tends to be a load of hooey, since some clients (rails in particular) do not handle nicely objects of the same type with heterogeneous data sets.

So.. it seems like Rest (which is not SOAP) makes it easy for the easy clients by skimping on the tools for the more complex clients. I can easily do jersey -> jersey, and I presume Resteasy -> Resteasy. But w/o that neutral definition.. cross implementation clients (robust ones) are actually harder.

Am I missing something?

    • bryankearney says:


      I have seen that..but it seems at a higher level then what I was asking for. Seems wierd there is no contract for the lower level interfaces.

  1. Casey Dahlin says:

    Nope. That’s the idea. Stop writing complicated software 🙂

    • bryankearney says:

      That is just it.. I dont think having a contract is complicated. Saying it is simple because it lacks functionality is not great. My car is 75% easier, because it is missing a wheel. Zippie.

  2. dgoodwin says:

    So for the contract issue, even if WADL is brushed aside by most, is it sufficient if you want to define such a contract, or is it somehow flawed?

    Contract issue aside, does REST then seem simpler than SOAP winds up in practice? I don’t really know one way or another but from what I’m reading many other benefits are mentioned, simpler to integrate with and understand, easier to develop, benefits from being stateless (scalable), and so forth.

    • bryankearney says:

      I think the answer is that “it depends”. If you do “stupid” rest (meaning not HATEOAS, closer to XMLRPC) then it is dirt simple to spin up a server in rails/jersey/etc and have it consumed by any number of clients. So.. very simple.. very light weight. Add a true Resource based API (not RPC style) and return links to relationships instead of hte object themselves (true HATEOAS) then it is a bit harder.

      SOAP for Java and Python clients is heavy, but pretty easy with the tooling. For ruby, I dont think it is very easy.

      So, the answer to your question I think it is that “it depends”

  3. XML-RPC is way easier and in hindsight, I should’ve just went with that 🙂

  4. Alex D says:


    HTTP has types. Look at the Accept and Content-type headers. what more would you want?

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