Dare Obasanjo disagrees with Steve Vinoski and Ryan Tomayko and makes the case for a REST description language:
The examples of Atom service documents and link elements in HTML, highlight that there is real world value in describing the interfaces to your RESTful Web Service. In addition, Atom service documents show that you can define an interface definition language for Web services without resorting to reinventing CORBA IDL (i.e. WSDL). So I respectfully disagree with Ryan Tomayko…just because my life is made easier with a service description language doesn’t make WSDL a good idea.
I’m not at all opposed to what Dare is suggesting — but I claim that an Atom service documents and link constructions in HTML GET forms is so wildly different from WSDL, IDL and other description formats for specialized interfaces that calling all of them “a description language” confuses the issue.
REST relies on hypermedia. An Atom service document does, too — WSDL and IDL don’t.
Totally agree. Additionally I think RESTful APIs can be compared with reflective APIs as it is possible to discover and explore such an API by using a restricted set of operations (the 4 HTTP verbs for REST and getClass(), getMethods() etc. for Java). Nobody would strike on the idea to define a domain specific interface definition for using reflection on a particular set of domain objects but would rather refer to the reflection API (for REST: HTTP spec) as well as to the application design (for REST: the protocol specification).
Instead of an IDL I would consider a BPEL pendant for REST way more reasonable. While BPEL describes the order of a set of message exchanges (that is necessary to fulfill a certain business goal), the REST world could benefit from a language that orchestrates a set of RESTful verbs in order to achieve transactions or stuff like that.