Re: RADL

On May 25, 2005, at 6:49 AM, Danny Ayers wrote:
>
> I couldn't help wondering why a Web resource description format like
> WADL didn't use the Resource Description Framework. For fun I've
> rewritten the WADL syntax example in RDF/XML (below).
>
Equal parts laziness and ignorance ;-).

> I very much like the lightweight design of WADL, though there are
> certain aspects I'm not altogether comfortable with. The first is the
> way resources are described - a URI identifies a resource, so a URI
> 'resource' element is rather unnecessary. More useful information is
> the nature(s)/role(s) of the resource in the service context. RDF
> properties would be an easy, standard way of expressing these (note
> that I haven't attempted to refactor this in the RDF/XML below).
>
I'd be interested to see that idea developed further.

> The extensive use of XSD typing, especially in the parameters, seems
> to run counter to the usual idea of RESTful services being
> loosely-coupled. What's there now seems closer to hard-wired RPC. It's
> prescriptive rather than descriptive.
>
To be useful, I think its important for a description to include  
information like the root element of any XML documents being  
exchanged. The use of XSD typing in parameters is optional but seemed  
like a useful addition so you could, e.g., restrict a parameter to  
being an integer rather than just leaving everything as a string.

I'm not sure what you mean by 'prescriptive rather than  
descriptive' ? The WADL doc just tells you what to expect, it doesn't  
force any particular style of use.

> An RDF-based alternative could work quite well at this point too,
> following the 'missing isn't broken' model [1]. Where parameters were
> required, this could be *described* using OWL  cardinality.
>
I'm not sure I understand the applicability of the 'missing isn't  
broken' model here. The WADL description just tells you what request  
parameters are supported, it doesn't force you to include them all,  
only those that are marked with required='true'. There's nothing  
forcing a description to list all possible parameters or even all the  
resources.

> I'm also not sure about enumerated representations, especially 'fault'
> - again it seems very RPC, rather than allowing for the full range of
> HTTP response codes. What I'm trying to say is that 400 isn't a HTTP
> fault but is associated with a valid representation of the resource. I
> do reckon 'fault' is a desirable piece of information, but would like
> (somehow) for it to be pushed up to refer to the application rather
> than the transport (or relate one to the other).
>
Enumerating the possible representations seems like a good idea to  
me, that way a user of the description can seem what representations  
are available and choose among them.

Fault is just a representation with an additional (optional)  
attribute that lists the possible HTTP status codes that can  
accompany the representation. This just seems like useful  
information, there's nothing preventing use of any HTTP response code  
and there's no requirement to list them all in the WADL description.  
HTTP defines the 4xx and 5xx status codes as error conditions but in  
some cases applications use 2xx status codes with some kind of  
application fault in the entity body.

Marc.

>
> [1] http://rdfweb.org/mt/foaflog/archives/000047.html
>
> --------------------
>
> <?xml version="1.0" standalone="yes"?>
> <application
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://research.sun.com/wadl wadl.xsd"
>     xmlns:yn="urn:yahoo:yn"
>     xmlns:ya="urn:yahoo:api"
>     xmlns="http://research.sun.com/wadl"
>     xmlns:w="http://research.sun.com/wadl"
>     xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>     xmlns:tns="urn:yahoo:yn">
>
>   <types rdf:parseType="Resource">
>     <include
>     rdf:resource="http://api.search.yahoo.com/NewsSearchService/V1/ 
> NewsSearchResponse.xsd"/>
>     <include
>     rdf:resource="http://api.search.yahoo.com/Api/V1/error.xsd"/>
>   </types>
>
>   <resources>
>     <resource rdf:about="http://api.search.yahoo.com/ 
> NewsSearchService/V1/newsSearch">
>       <operationRef rdf:resource="#NewsSearch"/>
>     </resource>
>   </resources>
>
>   <operation rdf:parseType="Resource">
>     <id>NewsSearch</id>
>     <method>get</method>
>
>     <request rdf:parseType="Collection">
>       <parameter w:name="appid" w:type="xsd:string"  
> w:required="true"/>
>       <parameter w:name="query" w:type="xsd:string"  
> w:required="true"/>
>       <parameter w:name="type" w:type="xsd:string"/>
>       <parameter w:name="results" w:type="xsd:int"/>
>       <parameter w:name="start" w:type="xsd:int"/>
>       <parameter w:name="sort" w:type="xsd:string"/>
>       <parameter w:name="language" w:type="xsd:string"/>
>     </request>
>
>     <response rdf:parseType="Collection">
>       <representation w:mediaType="application/xml"  
> w:element="yn:ResultSet"/>
>       <fault w:id="SearchError" w:status="400"  
> w:mediaType="application/xml"
>          w:element="ya:Error"/>
>     </response>
>
>   </operation>
> </application>
>
> (archived at http://dannyayers.com/2005/05/radl.rdf)
>
> -- 
>
> http://dannyayers.com
>
>

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.

Received on Wednesday, 25 May 2005 16:23:08 UTC