2006/5/10, Joe Gregorio <[EMAIL PROTECTED]>:
On 5/10/06, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> couldn't we have a similar constraint here (dispatching depending on
> media type; note that it's not conneg, it's far easier than conneg!
Dispatching based on media-type *is* content negotiation,
I disagree.
I mean, this is content negotiation:
1. Request: I want a representation of the resource identified by
this URI. I only support representation of those kinds:
application/atom+xml, image/jpeg, image/png and image/gif, preferably
not of type image/gif if other representations I support exist.
2. Server-side processing: find the available representations of the
resource, compute the "best match" given the client preferences given
in the request
3. Response: send the representation which "best matched" the
request, along with a Content-Location header giving the exact URI of
the sent representation (not necessary but it more obviously
illustrate the "dispatching" process)
This is, IMO, not content negotiation, only media type dispatching:
1. Request: please update the resource identified by this URI with
the following representation, whose media type is XXX
2. Server-side processing: I know that representations of type XXX
are treated by the "program" AAA, representations of type YYY or ZZZ
by the "program" BBB, and other representations are not accepted. As
the sent representation is of type XXX, I give it to the "program"
AAA.
3. Response: the "program" AAA does its stuff and generates the
appropriate response
the kind that causes so much grief.
I'm not talking about client-side media-type dispatching, "the kind
that causes so much grief", but server-side media-type dispatching.
--
Thomas Broyer
