On WSDL and silos

Paraphrasing Mark: Apps do not become magically interoperable simply by exposing a WSDL document. True interoperability is directly a function of the number of clients that can understand the application protocol encoded in that WSDL. (Insert obligatory reference to the REST principle of constrained interfaces).

Is there a RESTful corollary? Something like: Apps do not become magically interoperable simply by exposing representations of their internal resources in a RESTful manner using HTTP as the application protocol. True interoperability is directly a function of the number of clients that can understand the representation of a resource living behind a given URI.  

An example of this corollary: remember back in the wild days of HTML 1.0, when all the browser vendors were trying to out-innovate each other by coming up with a whole bunch of crazy tags? You could build a site that was theoretically interoperable (i.e. you implemented HTTP correctly), but at the end of the day that site still looked like crap in certain browsers.

This is an issue that is addressed partially by using the Content-Type: header appropriately. But even if we’re both speaking text/xml, if you send me 

<person>
   <name>Steve</name>
</person> 

when I’m expecting 

<entity type=”person”>
   <characteristic type=”name” value=”Steve” />
</entity> 

I’m still hosed. I suppose we could invent a whole bunch of app-specific content types, but that just seems to punt the problem over to a different part of the stack. 

In order 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 constrained interface principle seem to skip over that fact.

REST: it’s not just HTTP…