It's been a couple of days that I'm reading some articles about RESTful architecture. I have a (perhaps stupid) question:
Let me explain...
In SOAP-based web-services, clients have WSDL of the web service and they can generate any classes (such as data structures) used in server-side in their own project and use them in their development. So, clients could easily develop client application projects with WSDL files.
In RESTful web-services, as far as I know, there is no WSDL and SOAP files to describe the class files. So, how clients could be aware of data structures, classes and so on? How they can develop and predict the invocation output? I mean, is there any Web Service Definition Language (WSDL) for RESTful web services? How companies give their RESTful APIs to client customers?
Some REST implementations (like Jersey) implement WADL, which is sort of like WSDL for RESTful WS. But generally, a RESTful API consist of URLs and no much else. Certainly not custom data types. So a textual description of it should get you started, and make access to it a snap to implement (possibly using a library like HttpClient).
I like REST precisely because It's quickly (to develop,test, maintenance,etc) and you don't have so many restrictions as you have in SOAP. However, sometimes is good to have a wsdl, a "formal contract".
Regarding to your question, the companies often provide a "service catalog" which explains the response codes, the expected scenarios and examples of the common responses. However, don't misunderstand the schema concept. You have schemes in REST, but those schemes are provided but the owner of the web service, and they can change them with/out notification.
A couple of years ago I used the FB api, and was a mess, because they change the responses (schemes) all the time ...