A thought experiment on line between REST and POX...
Let's say there's an app that exposes domain-specific XML data via HTTP GET endpoints. That is, I can get back an XML document describing some application-specific entity by issuing HTTP GET's to URI's like the following:
http://foo.com/CustomerProcessor.aspx?methodName=GetCustomer&customerId=12
http://foo.com/CustomerProcessor.aspx?methodName=GetCustomerDetails&customerID=12
This is a pretty typical of many POX/Lo-REST applications out there. Question is, is this application also RESTful in the Fielding sense? Where do we draw the line?
One component of RESTful architectures is that resources are identified by URI's. So what's the resource being identified by these URI's? Is it the CustomerProcessor or Customer #12? Implicitly, I'm asking if you think query string variables are significant contributors to resource identity. Interesting how the same implementation can be RESTful or non-RESTful depending on how the architect who designed this system answers this question.
Another component of REST is the idea of stateful resources and representations of state. Is the methodName=GetCustomer a request for a specific representation of Customer #12, or the name of a method to invoke on the CustomerProcessor? Depends on how I choose to think about the implementation. Again, one answer is RESTful and the other isn't.
Based solely on these two points, I think there's a difference between REST-by-accident and REST-by-intent. Lot of POX applications are RESTful if you look only at the data retrieval side of things. The real differentiation between POX and REST comes in how they handle non-idempotent operations like updates.
Updates are where the RESTful idea of constrained behavior come in to play. RESTful architectures favor a proliferation of nouns over a proliferation of verbs based on the idea that it's easier to add new state to a system than it is to add new behavior. So what's the real verb in the POX example? Is it HTTP GET or methodName=GetCustomer? Depends. If I also allow HTTP GET's on URI's likehttp://foo.com/CustomerProcessor.aspx?methodName=DeleteCustomer&customerId=12, that's a pretty good indication that the underlying HTTP verb doesn't mean much (delete is not GET) and that the value of methodName is the thing that really carries the intent of the message. And as soon as you start inventing new verbs like DeleteCustomer and UpdateCustomer, you've broken the uniform interface (in this case, HTTP) and therefore aren't RESTful. However, if you use GET to mean GET and use POST to handle non-idempotent operations, you're still adhering to the underlying semantics of the HTTP verb...sort of. If you're using POST to handle both resource deletion as well as resource creation, you're still effectively creating your own application protocol for non-query operations. In effect, you have a uniform interface for GET and an application-specific interface for CREATE/DELETE/PUT. That's fine, but it's not REST.
Finally, the last and most nebulous component of REST is the grandiose-sounding principle of hypermedia as the engine of application state. In my mind, this is about building apps where navigation flow is handled by traversing URI's (e.g. hyperlinks) obtained from a response to a previous request. I like to rephrase this as a question: are your URI's really opaque to the client? That is, can a client interact with your system simply by using the URI's you gave it as part of a previous response? Or does getting work done on your system require clients to create their own request URI's based on how they know your system will interpret the contents? Of course, building 'hackable' URI schemes where the client can infer the URI for a particular application state is a good thing, but that's basically just an optimization. Clients should be able to use a RESTful application without being required to know how to construct the URI corresponding to a particular application state.
Extrapolating out the above to make some broad generalizations about POX and REST:
- POX applications generally lack a strong resource-centric model, instead preferring to use RPC-style semantics by encoding method names and parameter data in query string variables.
- That said, lots of POX applications can be considered RESTful if you look only at their data retrieval interfaces. This architectural overlap often happens by accident rather than intent.
- The line between POX and REST hinges on how an application handles updates and navigation flow. RESTful applications will use the constrained semantics of the HTTP interface to effect state changes in their application, and embrace the idea of hyperlinking as the mechanism of traversing the application's state machine. Conversely, POX application eschew PUT/DELETE in favor of application-specific verbs tunneled through HTTP POST. POX applications do not generally embrace hypermedia as the engine of application state, instead they present a URI-based RPC API for clients to consume ad hoc.
Not sure if that makes things clearer or not :)
