Re: Caveats for Web-friendly service description

On 5/31/05, Mark Baker <distobj@acm.org> wrote:
> What I mean by that claim is that I believe that doing this work in a
> manner consistent with REST and Web architecture means avoiding some
> common practices.  I'll use an example to illustrate...
> 
> Both WDL and WADL (and perhaps others, I just happened to notice these
> two did it) declare the list of possible response codes that a service
> returns, ala;
> 
> WDL: <wdl:output code="400 403 503" ref="yahoosrch:Error"/>
> 
> WADL: <wadl:fault name="searchError" status="400 403 503"/>
> 
> I don't think that's a very good idea, because if those descriptions are
> used to generate client code, then that code will be inconsistent with
> the HTTP spec since it says;
> 
>   "applications MUST understand the class of any status code, as
>    indicated by the first digit, and treat any unrecognized response as
>    being equivalent to the x00 status code of that class"
>     -- http://www.zvon.org/tmRFC/RFC2616/Output/chapter6.html#sub1

+1

> Another example of this is the use, in most of the description specs
> I've seen, of XML schema.  For the same reason as above, I generally
> think it's a bad idea to describe the data produced using a schema
> since schemas generally (DaveO's excellent extensibility advice
> notwithstanding) change foreseeably over time, and I don't want a change
> in the schema produced by a service breaking clients if I can help it.
> Instead, I'm more a fan of simply using a media type as a name for an
> open-ended sequence of backwards-compatible schemas (think "text/html"
> vs. HTML 2.0, 3.2, 4.01, etc..), as well as, of course, associating an
> extensible processing model to that media type to accomodate as many
> unanticipated extensions as possible over time.

Agreed. Just because something is a web service doesn't mean it's generating
output that is XML or taking input that is XML, and how exactly would you 
validate a PNG against a Schema?


> So what does such advice mean to a description language?  IMO, it means
> that we should be designing a forms language, not what is typically
> known to be a "service description language".  A forms language is
> processed entirely at runtime, and declares state transitions, possibly
> parameterized, of an application.  RDF Forms is a forms language.  WRDL
> is another.  WSDL 2.0 has some form features, but is predominantly for
> service description.

I'd like to see the definition of some hypertext that can be used
as the engine of application state. A crude core of my thinking is 
outlined in the introspection file of this article:

  http://www.xml.com/pub/a/2005/04/06/restful.html

That mirrors the kind of construction seen in the A9 search service:

  http://opensearch.a9.com/spec/opensearchquerysyntax/1.0/


  Thanks,
  -joe

-- 
Joe Gregorio        http://bitworking.org

Received on Wednesday, 1 June 2005 14:58:35 UTC