ROA vs SOA: The Uniform Interface

My conclusion is: REST was supposed to define a set of architectural constraints, but nobody is constrained by the uniform interface and many don't implement it or worse violate it. To identify those resources agreeing to abide is a contractual determination, not an architectural one.

Let's review what a uniform interface is, and then what the ROA uniform interface is. As a simpleton definition, a uniform interface means that for all things capable of responding to a request, the language to invoke the request is the same (aka uniform). This means the language is a system invariant as opposed to something that must be specified per target. This is important because it means that intermediaries can attach to the system and the semantics of any observed requests are transparent to the intermediary. This explaination is my own spin and interpretation. Consulting the authoritative source is (to me, YMMV) like reading a political speech: it says much that is often repeated by adherents but uses too many nebulously defined terms that at the end of the day don't convey any precise meaning. The uniform interface, as described by Fielding, is defined by four interface architectural constraints: identification of resources via a URI, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state. Fielding later explains: "REST enables intermediate processing by constraining messages to be self-descriptive: interaction is stateless between requests, standard methods and media types are used to indicate semantics and exchange information, and responses explicitly indicate cacheability." Generally, I agree there is tremendous value in having a standard set of operations with externally known, target-independent semantics. The idea in ROA is that all resources in the system can receive GET, POST, PUT, and DELETE. Unfortunately, very few people actually implement these faithfully, and there are other HTTP operations like TRACE, HEAD, OPTIONS, and CONNECT which are even less faithfully implemented. Almost all of the internet fails to implement the uniform interface. Browsers don't actually support PUT and DELETE, by the way. Lot's of resources even violate the normal meanings. As one example, ActiveMQ's is a message broker that allows HTTP GET to destructively dequeue a message. Is this "bad"? or useful?

I hate to come back to the contract question again, but how exactly do I declare that I do faithfully use the full uniform contract of ROA. How do I shout from the rooftops that my GETs are safe? I suppose somebody could publish an atom feed of all "know uniform" sites. The sad irony is that were such a way invented, it would express nothing more than that specific targets obey a particular interface (the uniform one). This is the problem with trying to avoid contracts - it doesn't work. The sad reality is that the uniform interface is not uniformly adopted. It'd be nice if it were, but alas, this is a pipe dream. It'd be nice if people wouldn't spam me, too.

Let's pretend that everybody gets religion and tries to follow the "spirit of the web". ActiveMQ only dequeues on DELETE. Even, then, there's the problem that POST doesn't actually have a standard meaning that can be predicted in a resource independent way. It's the operation with side effects, right? If that's all we can say about it, that's lame. It's also false: there's no guarantee that POST must have side effects on any particular invocation. The REST crowd cries with horror at the "abuse of the web" that occurs when somebody creates a SOAP interface and does a POST with an operation parameter of getPurchaseOrder to return a purchase order document. The offender is often lectured about the HTTP Spec, section 9.3 and 9.5 and the Axioms of The Web, and then referred to The REST Bible. Tim Berners Lee and Roy Fielding's contributions to the sciences and useful arts deserve respect, but only because they try to explain their points without the sophistry of appeal to authority, something lost on most REST advocates. Back to the point: there is nothing in the HTTP spec section 9.3 or 9.5 that implies you cannot embed a "GET equivalent" inside a POST, as SOAP often does. One of the (many) enumerated functions POST was intended to cover is that of "providing a block of data, such as the result of submitting a form, to a data-handling process" and " The actual function performed by the POST method is determined by the server ...". To the Turing machine at the other end of your POST there is no meaningful distinction between such an allowable data block and one that invokes "operations" via a string identifier.

When you look at TBL's document above, you do find this axiom that appears to forbid the practice. His argument for the axiom is that "The introduction of any other method apart from GET which has no side effects is also incorrect, because the results of such an operation effectively form a separate address space, which violates the universality." The axiom of universality in two parts states "Any resource anywhere can be given a URI" and "Any resource of significance should be given a URI." Keep in mind that resources in the semantic web can be "...anything - real objects, abstract concepts." The idea here is that since you are "obviously" just getting a resource, you should give it a URI and GET it.

Unfortunately, to denounce getPurchaseOrder relies on your desires as client rather than what I as the implementer have agreed to. How exactly how are you concluding from the name only, that "getPurchaseOrder" has no side effect? The WSDL doesn't specify that this is true and one of the SOA principles "autonomy" says the other details are encapsulated in a single point of control. Unless I explicitly gave you a commitment (and I didn't), you really you have no such guarantee. How do you know that my getPurchaseOrder implementation doesn't increment a counter somewhere as a side affect. How do you know it doesn't assign a random sales engineer's name from a rotating pool on each request? You want getPurchaseOrder to be side effect free, but that desire is all you have. Here's the problem: functionality changes over time. I may not be willing to commit to getPurchaseOrder being side effect free for now and all times. Even if it is truly side effect free, that's just for today. Will it stay that way? Maybe it wasn't put in a GET so that I can have the flexibility to change the operation's side effects next year when we get serious about Sarbanes-Oxley. The rule has to be that the operation is guaranteed to NEVER have side effects. The "axioms of the web" really don't contradict embedding GET in POST if the side-effect free guarantee isn't established. And that is 100% up to me as implementer to determine. You as client can never verify the call is side effect free, as I don't have to tell you everything I do when I receive your call, and you can never observe "all resources" because of the open world assumption on the web.

In summary, I wish the uniform interface of REST was actually adhered to by all HTTP resources. Even if it was, there is nothing nonconformant with SOAP. I think I could defend the proposition that SOAP is RESTful. Finally,in the real world, adherence to the uniform interface is not uniform, so there is no escaping the need for contracts to declare target specific interfaces.

Technorati Tags: rest soap roa soa web-services uniform-interface