Every URI on the web can be thought of as a service, though most only
implement the GET method. However, for more complex services, the HTTP
OPTIONS method would seem to be a viable candidate for providing
information about what verbs are available for the resource, what
parameters are required, and what other URIs provide related services.

From HTTP RFC 9.2 :
"If the OPTIONS request includes an entity-body (as indicated by the
presence of Content-Length or Transfer-Encoding), then the media type
MUST be indicated by a Content-Type field. Although this specification
does not define any use for such a body, future extensions to HTTP
might use the OPTIONS body to make more detailed queries on the
server. A server that does not support such an extension MAY discard
the request body."
- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

If something like a RSDL really is necessary, the response body of an
OPTIONS request seems like the place for it. The OPTIONS response
could also point you to related resources, either using extended
headers or something in the response body. For example:

OPTIONS /queue
- returns available methods: GET, POST
- notifies of related resource: /queue/[id] with methods GET, PUT, DELETE

Has something like this been explored previously?


On Fri, 18 Feb 2005 10:12:08 -0500, Josh Sled <jsled@...> wrote:
>
> On Fri, 2005-02-18 at 00:39, S. Mike Dierken wrote:
>
> > This looks like a description language for specifying available procedures
> > that can be called remotely. Is that what the description language is trying
> > to simplify and make available?
>
> For a variety of reasons, there seems to be two different things calling
> themselves REST: GET html form + POST / Fielding's dissertation / the
> Web as we know it... and "a Simple HTTP API via RPC and Encoded data
> (usually XML)" or "SHARE". I've been bothered [1] that there hasn't
> been a distinct name for it, so I made one up. I like it because:
>
> 1/ It doesn't confuse things.
> 2/ It's sympathetic to what these services want to do -- share data-
> and service- with the net and their callers.
> 3/ Maybe it's even marketing/friendly enough to get wide adoption.
>
> In any case, RSDL seems to straddle the fence...
>
> Hendy:
>
> 1/ defining and invoking the methods of interfaces really looks like
> RPC, to me. Why do you claim it's not?
>
> 2/ Let's say I have the example file, and want to call the
> "MyInterface#GetYou" operation ... how do I do that? What HTTP
> request should then occur? Is it something like:
>
> POST http://some.server/rest/1.0?rpcProcedure=GetYou
> <...content...>
>
> 3/ 3 of the 4 "may be useful" things in the last unordered list of Sec
> 1.1.1 are provided natively by HTTP. You may do better to embrace
> HTTP more completely rather than trying to be distinct from it.
>
> 4/ How do you handle method arguments, return-values and data-types? I
> don't think you can have RSDL without having RIDL; in fact I think
> they're really one-in-the-same.
>
> 5/ The variability introduced by spec language like that of the bullet
> point beginning with "Listing a method that isn't..." is a Bad
> Thing; it only makes life more complicated. I'd propose:
> "The <interface> attribute of the <method> element is required."
>
> You make a vague slight against RDF in 1.1.2, but you should really take
> a deeper look at it; you're sharing a lot with it, both in semantics and
> syntax.
>
> You should also look at RDF Forms [2], which does something similar.
>
> [1]
http://asynchronous.org/blog/archives/2005/02/11/amazons_restless_ws_api.html
> [2] http://www.markbaker.ca/2003/05/RDF-Forms/
>
> ...jsled
>
> --
> http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
>
>
> Yahoo! Groups Links
>
>
>
>
>