On Nov 9, 2006, at 4:29 AM, Jerome Louvel wrote:
>
> The current WADL specification seems to limit itself to describe the
> expected behavior of the client-side of an application. It would be
> good
> also to make sure it fully specify how the server-side should
> behave (or be
> generated).
>
The intent behind WADL is to describe the resources that make up an
application, the URIs that identify them and the HTTP methods they
support along with the expected inputs and available outputs. As such
it does describe the externally-visible behavior: "send this type of
request to a particular URI, you can select from this set of
available response formats".
> For example, after section 2.5.4 (Generating Resource Identifiers)
> there is
> no section specifying how the parsing/handling of such Resource
> Identifiers
> should be done on a server.
WADL specifies the format of the URI (building on the URI template
internet draft) but its left to the server how best to match a
particular URI to some executable bit of code (or perhaps a static
file). I think that process is quite specific to the capabilities of
the technology in use.
> In the Restlet API, we just added support for
> path parameters (see http://www.restlet.org/tutorial#part11 for a
> usage
> example). In the server-side implementation we decided to match all
> the
> "unreserved" URI characters when parsing each path parameter.
>
Looks good !
> Probably that's something that should be covered in the URI
> Template RFC
> too?
>
I think it might be useful if there was some discussion of matching a
URI to a URI template in the internet draft, currently it really only
discusses generating a URI from a template. I think it would be going
too far to extend that to matching a URI to an executable code module
though, that should be left to server technology specifications.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s