Is it a good idea to make your WADL available?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Is it a good idea to make your WADL available?

Mark Baker

On 9/6/06, [hidden email] <[hidden email]> wrote:
> Converseley, if you send out an HTML form that builds URIs in my domain,
> the story is different:  you can't commit me as a URI assigment authority,
> unless I have somehow delegated that capability to you.  So, it depends
> where the form or WADL comes from, IMO.

Oops, yes of course, agency is also of critical importance.  I should
have channeled Rohit;

http://www.isr.uci.edu/~rohit/ARRESTED-ICSE.pdf

Mark.

Reply | Threaded
Open this post in threaded view
|

WADL and Dynamic Interfaces

Jeffrey Winter
In reply to this post by Mark Baker

 
It occurs to me that WADL needs some mechanism to indicate that a
particular request may have a variable number of arguments that can't be
discovered until runtime.  Consider the following resource definition:

  <resource name="orderSelector" path="/orders/{sub-selector}">
    <method href="#orderFetcher"/>
  </resource>

On the server, the {sub-selector} could ultimately be mapped to, say,
some named SOL subselect clause that requires some number of parameter
values (e.g., a date range, order-by column list, etc.)  

  /orders/by-date?start=2001&end=2006
  /orders/by-customer?name=smith
  /orders/by-store?id=BostonLoc2

If there is a static number of sub-selectors, these could be explicitly
detailed by concrete resource and method definitions with each parameter
explicitly defined.  But if new sub-select clauses can be added to (and
removed from) the system at runtime, there is no mechanism in WADL to
capture the fact that the names and number of the parameters is
variable.

While the WADL could be generated at runtime, many of the stated use
cases are for more off-line scenarios.  

Perhaps some indicator could be defined to capture a variable number of
parameters:

  <method id="m1">
    <param name="p1"/>
    <param name="p2"/>
    <variable-params/>  <!-- a unknown number of other params -->
  </method>


12