Aehso’s Output

Describing RESTful services.

A recent discussion on rest-discuss related to describing RESTful resources has lead to interesting discussion by Aristotle Pagaltzis, Stefan Tikov and Don Box on the topic.  They highlight a couple of issues that have been bugging me (at Oisin’s expense I think!):

• How should RESTful clients bootstrap into a RESTful system, or rather, how does the client determine the correct payload to send to the first RESTful resource it interacts with?  Currently it appears that there must be some out-of-band definition of the first RESTful resource request that the client has ‘baked-in’ in order to initiate a conversation with a set of RESTful resources.  HTTP Web browsers solve this problem through (bookmarked) URLs.  Should all RESTful resource clients do the same?
• How should RESTful clients interpret arbritrary XML response payload?  The response XML is presumably defined by a schema (somewhere) but I’m wondering how is a RESTful client expected to interpret the semantics of the XML unless it has prior knowledge of the schema.  Is this prior knowledge just assumed? Again, HTML browsers succeed in this regard because they are build on the semantics of the HTML language schema.

I’d be very interested if anyone has insights into the above two questions.  If knowledge of the schema(s) is assumed (Aristotle’s post implies this) then perhaps all folks are looking for is guidance on how to determine which XML element definitions are expected/returned by RESTful resource request/reponses. 

Perhaps that’s where the value in WADL lies.  Unfortunately WADL seems to promote static resource set definitions, as WSDL does for WS-* service endpoints.  Perhaps if the WADL resource set definitions could also reference other WADL resource set definitions then we might have something a bit more dynamic?

No comments yet.

Leave a comment