Trying to clean it up and put it to bed…
July 6th, 2006 2:04:07 pm pst by 
Sterling Camden
Apparently I was mistaken the other day when I said that I had never worked directly with REST.
A post from Assaf the next day led me to dig further into what REST is. Turns out I’ve been doing a lot of that. Any time you write an RSS or ATOM feed and make it available at a URI, that’s an example of REST. Ruby on Rails uses RESTful URIs in their implementation of the model-view-controller pattern. Some even say that every web page implements REST, though that’s stretching the definition pretty thin.
I haven’t yet implemented any web services using REST, though. I’ve always used SOAP for that. I can see how REST could simplify the implementation and speed up execution, not only by removing the envelope but also by transferring the method name to the URI. It separates the calling mechanism from the document, so you only have to transmit and parse the data and its metadata.
On the down side, you must create a consistent and extensible URI scheme (like Rails has) in order to do anything complex. You must validate that clients are using the URIs in an acceptable manner (just as you have to validate the XML in a SOAP request). Seems like you would also want to rely more on the web server for implementing security, in order to use more GET operations for retrieval rather than posting credentials or tokens. Not that there’s anything wrong with that.
But I was having trouble understanding Assaf’s distinction between REST and XML/HTTP, until I ran across this post from April, 2005 by Dare Obasanjo. At least I think it’s the same distinction, or part of it. Distilled into a nutshell (and mixing my metaphors), you can’t call it RESTful if an HTTP GET operation can be used to modify data on the server. Dare gives some good examples of APIs that violate that rule of “safe and idempotent methods”. A RESTful system should use HTTP POST, PUT, or DELETE for operations that affect server data.
But I think there might be more to Assaf’s distinction than that — particularly in drawing a line between REST and “SOAP Lite”. Maybe he’ll stop by in the comments and clarify it for me. Specifically, in what ways did this promise fail?
BTW, I agree with Assaf’s main point. The interface contract between disjoint systems can never be an “implementation detail”.
Posted in Coding...OK? | 
7 Comments » RSS 2.0 | Sphere it!
Subscribe by Email
Axis2 and Indigo are great, I love them. They’re both WS stacks done right. But they don’t do REST. They slapped the REST insignia for marketing purposes recently. Evidently some analysts are buying into that.
They don’t make a distinction between GET and POST, you accept either one as if they’re both the same. And you can’t have URLs with abundance, the only thing you can have are your limited set of endpoints.
What they do is (7 year old) WSDL 1.1 HTTP bindings using XML MIME types. In short. SOAP without the envelope. Not you’re right to call it XML/HTTTP. But it’s XML/HTTP done the WS way.
WS-* and REST are two different approaches. They can both carry different payloads. They can both carry XML (and HTML and SVG and JPEG and you name it).
If you want to understand the difference, here’s a simple (but not trivial) excercise.
Build an Amazon-like Web site that uses HTML/HTTP payloads but is build using a WS stack. In other words, GET and POST are the same, HTTP headers (like cookies, redirect) don’t exist, and URLs are rationed out, you only get 30 of those. For the entire site.
How well would it work?
OK, got it. Thanks for the specifics, Assaf.
BTW the Web only needs two verbs: do and go. People blog and Wiki every day using just GET and POST.
Using more than two verbs is still exotic (WebDAV, SVN, Rails 1.2). Ironically, WS stacks like adding this feature first because it’s easy to do.
But they have a problem relying on HTTP/URLs to full extent because they’re built to replace HTTP with the WS-* protocol. And they only use HTTP because it’s port 80. Port 80 goes through the firewall.
Granted that new WS-* protocol does a lot of interesting and useful things that HTTP doesn’t do. It does one-way messaging, fancy routing, transactions, mediation (not just proxying), etc.
And those are all useful in many applications.
My only argument is, pick one or the other. My iPod is a great portable sound system, but it’s no Harman Kardon Logic 7. Likewise, my WS stack will never do REST right. And vice versa.
Yeah, people need to get over the software monotheism. A certain amount of diversity leads to the evolution of best solutions. Thanks again for your comments, Assaf.
Hope I clarified more than confused.
[...] Trying to clean it up and put it to bed… — Chip’s Quips (tags: dev soap rest xmlrpc) [...]