On Feb 24, 2009, at 7:24 PM, Houghton,Andrew wrote:
> I'm trying to figure out whether I should use embedded resources or
> not. I have the following WADL:
>
> <application>
> <resources base="http://example.org/">
> <resource id="ID.1" path="">
> <resource id="ID.1.1" path="">
> <method name="GET" />
> <method name="GET" />
> </resource>
> <resource id="ID.1.2" path="">
> <method name="GET" />
> <method name="GET" />
> </resource>
> </resource>
> </resources>
> <resource id="ID.2" path="foo" />
> </application>
>
The above isn't valid, you can't put resource at the top level.
> basically I want to group similar access to a resource under ID.1.
> For example, if I do content negotiation for an RDF-XML or RDF-
> Turtle representation, then I would like to group it under an RDF
> access to the resource vs. HTML or XHTML representation, for example
> like this:
>
> <resource id="ID.1.1" path="">
> <doc title="RDF access to resource" />
> <method name="GET">
> <request>
> <param name="Accept" style="header" required="true"
> repeating="false" type="xsd:string">
> <option value="application/rdf+xml" />
> </param>
> <param name="Accept-Charset" style="header" required="false"
> repeating="false" type="xsd:string" default="*" />
> <param name="Accept-Encoding" style="header"
> required="false" repeating="false" type="xsd:string" default="*" />
> <param name="Accept-Language" style="header"
> required="false" repeating="false" type="xsd:string" default="*" />
> </request>
> </method>
> <method name="GET">
> <request>
> <param name="Accept" style="header" required="true"
> repeating="false" type="xsd:string">
> <option value="text/turtle" />
> <option value="application/x-turtle" />
> </param>
> <param name="Accept-Charset" style="header" required="false"
> repeating="false" type="xsd:string" default="*" />
> <param name="Accept-Encoding" style="header"
> required="false" repeating="false" type="xsd:string" default="*" />
> <param name="Accept-Language" style="header"
> required="false" repeating="false" type="xsd:string" default="*" />
> </request>
> </method>
> </resource>
>
> I realize that I could have written it as:
>
> <application>
> <resources base="http://example.org/">
> <resource id="ID.1" path="">
> <method name="GET" />
> <method name="GET" />
> <method name="GET" />
> <method name="GET" />
> </resource>
> </resources>
> <resource id="ID.2" path="foo" />
> </application>
>
> So my question is: is it OK to use embedded resources in this manner
> and what is the impact on the path for the embedded resource, e.g.,
> section 2.5.1 Generating Resource Identifiers is playing with my
> mind such that I'm not sure that the path for ID.1.1 and ID.1.2 will
> still be http://example.org/.
>
Hmm, as written I think the empty path would work the way you want but
I think that is actually a bug rather than a feature. Subresources
aren't really intended to be used the way you are suggesting. I think
you should take a look at resource_type instead, something like:
<resource_type id="RDFEnabled">
<method name="GET">
<response>
<representation mediaType="application/rdf+xml"/>
<representation mediaType="application/x-turtle"/>
</response>
</method>
</resource_type>
The sibling representation elements indicate that two different media
type are available and the standard HTTP conneg can be used to select
between them so there's no need to explicitly add request params for
those headers.
Given this you can then declare that some resource supports RDF as
follows:
<resource type="#RDFEnabled" path="somepath">
<param .../>
...
</resource>
HTH,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
Sun Microsystems.