I sent this as an internal email.. but figured I would post the question as well. File this into the “I dont get it” category. Not as bad as Google Wave, but close.

So.. I hear that Rest is a panacea, but mostly because it is “Rest not SOAP”. I actually understand many of the benefits that REST is gives you:

1) I can use a simple http client to access resources, therefore it is easier to adopt.
2) I inherit alot of the WS-* enhancements from the underlieing http transport, so the frameworks are lighter weight.
3) The ability to use the service both by a client and a browser.. mashups become easy.

What I keep getting hung up on is the absence of a formal description of the interface. I see WADL, but whenever I dig into this it seems to get brushed aside as a nuisance. If i want to write typed clients, then I need to have some formal contract of what can be passed in and what is returned. This contract seems to be what alot of the cruft around SOAP is for. Is there something I am missing with this? The answer the books/articles seem to give is “who needs a formal spec, it is all URI’s”. This tends to be a load of hooey, since some clients (rails in particular) do not handle nicely objects of the same type with heterogeneous data sets.

So.. it seems like Rest (which is not SOAP) makes it easy for the easy clients by skimping on the tools for the more complex clients. I can easily do jersey -> jersey, and I presume Resteasy -> Resteasy. But w/o that neutral definition.. cross implementation clients (robust ones) are actually harder.

Am I missing something?