Marc,
[...]
> 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.
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.
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
[..]
> 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.
> > 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 :-)
> 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.
Best regards,
Jerome