There’s a flurry of discussion about whether or not, in the world of REST, you need some sort of formal specification for the services you’re offering. My conclusion: yes, but in a very application-specific way.
If you want to read up on the debate, check out Sam Ruby and Ryan Tomayko (who’s hilarious while being insightful) and follow some pointers. But the piece that made the penny drop for me was Dare Obasanjo’s Myth: RESTful Web Services Don't Need an Interface Definition Language.
I’ve always had this internal voice telling me that Web Services do really need some sort of a way to declare them. I can remember, years and years ago, Nelson Minar saying “All I want is a .h file for my Web Service” and thinking yes.
WSDL clearly isn’t the answer, but that’s because WSDL sucks, deeply and totally. I have had hopes for WADL, and still do. But I have to say, it hasn’t been fully obvious to me how you’d actually use such a beast. So I had this little voice in the back of my head muttering “YAGNI”.
Then after reading Dare’s piece, it dawned on me that I just spent the last three years of my life helping develop a Web Service Specification language, namely the Atom Publishing Protocol’s Service Document. Plus, I’ve written a bunch of software that processes them.
But... the APP Service Doc is totally specific to the needs of one particular RESTian protocol. So, we have existence proof that there is at least one useful instance of a service declaration. We do not really have existence proof that such a thing can be generalized across the needs of multiple protocols or applications.