Anybody who has worked with WSDL-based Web Services knows that the loose coupling they promised was a challenge to achieve. One silver lining around this cloud big-vendor SOA was the rise of RESTful approaches to building Services. If you’re building hypermedia applications following REST, the story goes, then the combination of hypermedia-based discovery, opaque URIs, and the uniform interface of REST will provide lightweight loose coupling between clients and resources where Web Services fell short.
Dig a little deeper, however, and the enterprisey world of Web Services soon collides with the Web-centric world of REST. In the enterprise (SOA) context, Services are interfaces to legacy applications and data. They come with structure and complexity that REST’s uniform interface can’t deal with directly. The problem: standard Internet Media Types (formerly called MIME types) don’t provide sufficient semantic detail for typical Service interactions.
Enter the Custom Media Type. Standard types like text/html, application/json, and application/xml don’t provide nearly the semantic detail you require for establishing arbitrary system-to-system interactions with a Service. Even application/atom+xml or application/rdf+xml or the like doesn’t cover it. So you create a Custom Media Type like application/vnd.zapthink.PO+xml, which would represent ZapThink’s custom purchase order format, for example.
What’s next? Publish your Custom Media Type to all potential recipients. Make sure they’re using it properly. So far, so good. But then it comes time to make a tweak to it, so you create a new version, say application/vnd.zapthink.POv2+xml. Only now all your clients break. Tight coupling in action. Oops!
So, have we really solved the coupling problem by moving to REST? Or have we taken the tight coupling pea and moved it under a different shell? Abracadabra! You pays your money, you takes your chances.
