[Steve remarks: I'm including Patrick's link to his response above, but I want to note that the entire premise of his response is based on the idea that I wrote my posting about schema, which is incorrect. Patrick even titled his response "steve vinoski on schema." Unfortunately for Patrick, I was not writing about schema, and the word "schema" does not even appear in my posting. I was writing about interface definition languages, which are not at all the same thing as schema languages. So take his response with a large grain of salt.]

I think that definition/schema/constraint languages can help to describe complex representations better. We can guess/induce structure of simple representations by looking at several examples, by “browsing” resources and by reading informal comments.

But for more complicated representations I do not mind to look at schema (more formal definition). Schemas (and constraints) can also be used for efficient validation/screening of representations.

If we have to use some static language (or framework) for designing a client of a REST-based service then schemas can help to build (manually or automatically) “helper” classes. But these static classes can “freeze” representations and can restrict our ability to build more adaptive clients.

Dynamic languages can build helpers “on the fly”, so we do not feel this “freezing” effect. XSLT, XQuery, XForms support flexible data representations by design so they also play well with REST-based services.

I think that in ideal situation, all components of RESTful solution (including GUI) should support dynamic/flexible data representations. In this case schemas can play positive role, they do not create “freezing” effect and do not restrict ability to adapt.