ParaphrasingMark:Apps do not become magicallyinteroperable simply by exposing a WSDL document. True interoperability isdirectly a function of the number of clients that can understand theapplication protocol encoded in that WSDL. (Insert obligatory reference to theREST principle of constrained interfaces).
Isthere a RESTful corollary? Something like: Appsdo not become magically interoperable simply by exposing representations oftheir internal resources in a RESTful manner using HTTP as the applicationprotocol. True interoperability is directly a function of the number of clientsthat can understand the representation of a resource living behind a given URI.
Anexample of this corollary: remember back in the wild days of HTML 1.0, when allthe browser vendors were trying to out-innovate each other by coming up with awhole bunch of crazy tags? You could build a site that was theoreticallyinteroperable (i.e. you implemented HTTP correctly), but at the end of the daythat site still looked like crap in certain browsers.
Thisis an issue that is addressed partially by using the Content-Type: headerappropriately. But even if we’re both speaking text/xml, if you send me
<person>
<name>Steve</name>
</person>
whenI’m expecting
<entitytype=”person”>
<characteristic type=”name” value=”Steve”/>
</entity>
I’mstill hosed. I suppose we could invent a whole bunch of app-specific contenttypes, but that just seems to punt the problem over to a different part of thestack.
Inorder to interoperate, two parties need to agree on both the verbs they use as well as how the nouns are represented(why else would we have RDF?). Most discussions of REST and the constrainedinterface principle seem to skip over that fact.
REST:it’s not just HTTP…
