On Nov 9, 2006, at 12:33 PM, Jerome Louvel wrote:
>
>> 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".
>
> That makes sense even if in my mind WADL was taking a more neutral
> point of
> view: describing the "interface" of the application. Like its
> useful to be
> able to generate client stubs from a WADL file, it would also be
> useful be
> able to precisely generate server skeletons from the same WADL,
> independently of the actual technology used.
>
Agreed. I'd add the ability to automatically generate a WADL for a
collection of skeletons.
> Right now for example, if you specify a path like:
> "widgets/{categoryId}{itemId}", it's difficult to generate a
> skeleton for a
> dynamic application that will automatically extract the value of each
> parameter. The type of the parameter might help to determine a parsing
> algorithm but if both "categoryId" and "itemId" are strings, then it's
> impossible.
>
Yes.
> It would have been great to constraint a bit more the path
> templates, saying
> for example that:
> - parameter values can not contain reserved characters
> - two parameters in the same segment must be separated by a reserved
> character
>
This was discussed on the URI mailing list and remains an open
question. I'm still undecided on the best approach. See http://
lists.w3.org/Archives/Public/uri/ for the archives.
It would be useful to be able to specify templates like:
http://example.com/foo/bar/{path}
which would match any URI starting with
http://example.com/foo/bar/
but that would require allowing reserved chars in parameters values.
> [..]
>> 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.
>
> Sure it is specific, but if you are generating a dynamic
> application, based
> on Servlet/PHP/RoR/..., then it's nice to know that the WADL
> document will
> unambiguously allow you to do so.
>
> We often think about Web services as someone providing a remote
> service and
> publishing the interface specification to access it. But if you
> need to
> implement some kind of call-back service, it is useful to provide a
> WADL
> document for it and let the implementers of the call-back servers
> generate
> the skeleton from WADL, in any technology that suits their needs.
>
Agreed.
>>> 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.
>
> Great! Let me know if there is a better way to report this comment
> on the
> RFC. As you are one of the authors, I guess I'm all set :-)
>
Join the mailing list:
http://lists.w3.org/Archives/Public/uri/
As somebody building code based on the draft, your feedback would be
very useful.
>> 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.
>
> Absolutely, beside the restriction on path parameters that I'm
> proposing
> above and maybe other similar discussions, I don't think we need to
> extend
> the scope of the RFC or of WADL to specify the server technology to
> use.
>
I think we agree then.
Thanks,
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s