Eric Roch recently blogged (Gartner on SOA vs. WOA) about my REST interview and he asked an excellent question: “So let’s look at the [REST] constraints, can someone please tell me which of these constraints solves data semantics problems?”
The answer is the uniform interface constraint (UIC), which you can also think of as the “generality constraint”. Since an interface is composed of identifiers, formats, and protocol operations, the (UIC) mandates that:
- Identifiers be as generic as possible
- Schemas be as generic as possible
- Protocol operations be as generic as possible
for the type of application being architected.
Everyone who’s looked at REST now seems to get the generic protocol operations part: GET, PUT, POST, DELETE, etc. And some are now getting the generic formats part: Atom Publishing Protocol, GData.
But very few are focusing on the generic identifiers part yet — at least in terms of explicitly RESTful thinking. The closest thing to generic identifier work in enterprises is master data rationalization. Gartner defines master data as consistent and uniform identifiers and attributes for key business entities used across many business processes (at least that’s the gist of our definition). To make the master data connection to REST explicit, “consistent and uniform” identifiers across many processes translates into generic identifiers, or if you prefer Roy’s terminology uniform identifiers.
So REST doesn’t so much solve the data semantics problem; rather, properly understood, REST’s UIC puts the data semantics problem, ie mandating uniform, generic semantics instead of ad hoc, specialized data semantics, front and center. REST is the only architectural style I know of that makes interface generalization the primary imperative. On the other hand, WS-* implicitly or explicitly encourages interface specialization. Steve Vinoski has a great article on the evils of interface specialization: Serendipitous Reuse.
Hope that helps clarify.