Morning Coffee 90 – REST Response Roundup

Last week, I asked a REST Question: is it still REST if you don’t use HTTP? My interest in durable messaging is well documented, so I want is to see a RESTful approach combined with a durable messaging. We all know my durable messaging tool of choice, though I’d trade SSB in a second for something that provided durable duplex messaging in a standard way.

Anyway, there were some fairly interesting responses that I wanted to highlight.

Probably most interesting to the discussion at hand was John Heintzcomment pointing out the existence of “Waka” ,  a new transfer protocol to replace HTTP from Roy Fielding. The fact that Dr. REST is working on a new protocol that’s designed to be more RESTful than HTTP should put to bed any REST “is and only is” HTTP arguments.

Erik Johnson agrees that you can separate REST and HTTP, but he thinks I ought to call it something else. He suggests “resource-oriented” – have we created a new TLA here? Are you down with ROA, ROAD, ROD, ROP and all the other acronyms we could spawn?

Nick Malik breaks out the IFaP acronym – Identifier, Format, Protocol – and points out “Each of the successful Internet standards, from HTTP to SMTP, has an IFaP at the heart of it.” But does anyone think SMTP is RESTful? I don’t. I think standardization of IFaP’s is on par in importance with RESTfulness, but they’re orthogonal. That is to say I think Nick’s wrong – I’m guessing we’ll go a few rounds on this when he gets back from Nashville – or should I say, if he gets back? 😄

Arnon Rotem-Gal-Oz has been wondering about REST without HTTP the same way I have, but he doesn’t really go into detail as to why. I want durable messaging, Arnon mentions something about topic hierarchies. Couldn’t you do that with HTTP, Arnon? He also points out a new DDJ article on REST. It’s good, if high-level overview-y.

Pat Helland writes that Every Noun Can be Verbed. It’s more related to CRUD is CRAP than REST == HTTP, but it’s well worth the read. His point about using filling out a form being CRUD, but then handing the form over to someone else being an invocation of behavior is fairly eye-opening. As long as you “interpret the durn’ things with the correct semantics”, it doesn’t really matter if they’re nouns or verbs.

Last but not least, Ted Neward and Adrian Trenaman discuss SOAP vs. POX over on The Server Side. They focus too much on SOAP encoding (isn’t that dead yet?), but near the end Ted points out: “Problem is, REST assumes that you want to carry all of the state in the payload itself, and for a modern enterprise system, or, hell, even for a game, that’s not always a safe assumption.” Doesn’t address my questions about using REST without HTTP, but a very good point nonetheless.

Comments:

Hi Harry, > but he doesn't really go into detail as to why. I thought I did explain it - anyway I'll try that again REST is said to be an architectural style - i.e. it has components, relations, attributes and constrains on how to use all of them - e.g. uniform interface etc. If it is an architectural style then you should be able to apply it in different technologies - I know I can do that with other architectural styles I know like SOA, Client/server, pipe and filters etc. For me it is interesting on the theoretical level as a way to look at architectural problems and principles but also on the practical level since you can't always use HTTP in a project or you may have to mix several communications protocols etc. Arnon
Gourmet coffee at coffeebreakusa(dot)com