capabilities lookup: it's the meta ...

[Grant Monroe]

I think that this is definitely on the right track conceptually, but
creating a new HTTP method sounds a bit impractical. I'm not even sure
if you can get Apache to accept a request for an unrecognized http
method. Also from a consumer implementation standpoint, this would
complicate things. For example, python's urllib2 could not be used for
fetching because it is only designed to work with HTTP. I'm also not
sure how web proxies would handle requests for a different method.

Grant Monroe

On 11/16/05, Ernst Johannes <jernst+lists.danga.com at netmesh.us> wrote:
> Something else had been bothering me about some of the capabilities
> lookup alternatives that we'd been discussing. I hadn't quite been
> able to put it into words, but finally, now I know what it is ... and
> I'm eager to share ;-)
>
> FIrst, a rehash.
>
> The operation that we are trying to define is
> "given this URL, tell me what its capabilities are"
>
> Then, an insight.
>
> This is, if there ever was one, a "meta" traversal. Similar to
> "given a Java/C#/Perl/PHP/whatever object, tell me what methods I can
> invoke on it", or
> "given a URL, tell me what its properties are" (like the PROPFIND
> method in WebDAV)
>
> Conceptually:
> This is not about obtaining the resource according to a different
> surface representation.
> This is also not about qualifying the GET operation of the URL with
> additional parameters.
> This is a genuinely new kind of method, a "META" method, so to speak:
> we are not attempting to "GET" the resource, or "POST" or "PUT" or
> "DELETE" etc. -- instead, we are asking for its meta-data. (well, a
> particular kind of its meta-data, namely what YADIS calls its
> capabilities)
>
> This is worth repeating: It is a GET, but not of the resource, but of
> its meta-data.
>
> Maybe the best parallel, in a language such as Java, would be
> "given this object, tell me what interfaces it supports". (please
> interpret the word "interfaces" loosely here, on the same abstraction
> level as capabilities in YADIS, I don't mean to talk about GET and
> POST etc.) as opposed to "give me an HTML or TXT or Serialized
> representation of the object" which would be an entirely different
> kind of request.
>
> So ...
>   ... the conceptually cleanest way to support this "meta" operation
> would be to add a new verb to HTTP ("GETMETA" comes to mind) -- like
> WebDAV did. In fact, there are many parallels here because a big
> chunk of what WebDAV is all about is to deal with additional meta-
> data that plain HTTP knows nothing about.
>   ... but assuming we don't want to define additional verbs for the
> REST / HTTP vocabulary, which would probably be a bad idea for a
> range of other reasons
>   ... assuming that you guys agree with me that "meta" is really what
> this is all about
>   ... the engineering problem in front of us seems to be:
>
> "given that we have a genuinely different kind of operation on a URL
> than people normally do these days" (side note: I very much agree
> with Mart's comment on the wiki that this capabilities/meta lookup is
> going to be much more broadly useful than "just" for identity) "how
> are we best going to use the means at our disposal to emulate this
> new operation?"
>
> Is that an accurate description of the problem?
>
> Note that any "meta" operation (whether in YADIS or wherever) is
> genuinely orthogonal to any parameters that specify which format the
> client wants the response to be in. Just like in plain normal use of
> HTTP, as a client I should be able to say "I like HTML better than
> PDF better than TXT" (if I'm a human) vs. "I like XML only" (if I'm a
> machine) for the meta-data of the URL, not just the resource behind
> the URL.
>
> That's the other thing that has bothered me in the current proposals
> without being able to express it so far: we seem to have assumed that
> the capability query only makes sense for machine clients. But upon
> reflection, I don't think so: as a human, I also want to know what a
> given URL can do, and I want to know in HTML because I like it better
> than PDF better than TXT and I don't like XML. (Just as an example
> for the preferences of a human client).
>
> Ergo, the "Accept" specification is, and must be, orthogonal to the
> "Meta" specification (in whatever form we will settle on), in order
> to be architecturally clean.
>
> In other words, I have decided to be very much against (sorry, guys)
> using the Accept header to emulate a "Meta" operation because it
> collapses two orthogonal things onto the same dimension, and that is
> a big no-no in the architecture book that I'm following ... because
> sooner or later, we'd want to disentangle the orthogonal dimensions
> and we won't be able to if we go down that route.
>
> Can we agree on whether this is an accurate description of the
> problem first before figuring out what that means for the protocol? I
> would have a proposal that turns out to be only a minor
> modification ... but problem description first.
>
>
>
>
> Johannes Ernst
>
>
>   http://netmesh.info/jernst
>
>
>
>
>
>
>