Re: Summing up on visibility(?)

Mark Baker <distobj@acm.org> wrote on 01/09/2003 09:39:18 PM:

> Chris,
> 
> On Thu, Jan 09, 2003 at 04:57:54PM -0500, Christopher B Ferris wrote:
> > Mark,
> > 
> > This started out with an example using POST. You promptly changed it 
to 
> > PUT
> > but none of this addressed the point I was attempting to make with 
POST.
> 
> I used PUT because it's easier to explain what it means than POST (I
> speak from experience here, both as a learner, and a learnee 8-).  But I
> wouldn't say POST is "more general"; GET, PUT, and POST are as general
> as one another, but they each do different things.  There's zero overlap
> between them.  So the principle is the *same* in those two cases, as it
> would be for GET.

I'm not certain that I would agree.

GET: "The GET method means retrieve whatever information (in the form of 
an
   entity) is identified by the Request-URI."
PUT: "The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI."
POST: "The POST method is used to request that the origin server accept 
the
   entity enclosed in the request as a new subordinate of the resource
   identified by the Request-URI in the Request-Line. POST is designed
   to allow a uniform method to cover the following functions:

      - Annotation of existing resources;

      - Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      - Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

      - Extending a database through an append operation.

   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI."

Of course, the "usually dependent on the Request-URI" bit suggests to me 
at least that
it could depend upon other aspects of the request message, including the 
content of the
entity body of the message, HTTP headers, etc.

Bottom line, POST is fuzzy because it really can take on a number of 
different
purposes, depending upon what the owner of the resource wants it to mean. 
I also see
nothing that suggests that it cannot have multiple meanings based on 
something in the
message other than the URI itself (e.g. based on the content of the entity 
body of the
request message).

The one purpose that I think most people have for POST is the third use 
case, would
you not agree?

> 
> The simplest example I know to explain what POST means is;
> 
>   frame.add(dialog)
> 
> where POST means something very similar to "add" (except it's for data,
> not objects).  See Walden's "known state" example earlier, as it may
> help explain why POST can't do PUT things;
> 
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0326
> 
> On to your example ...
> 
> You named two wrappers, "Review" and "Feedback".  I don't know exactly
> what you meant by each of those (i.e. nouns or verbs), but given the
> topic of discussion, I assume that "Review" is a verb.  So you might
> use it like;

I should have been more clear... to be honest, it doesn't matter if they 
are
verbs or nouns. The intent that I had for the example was to illustrate 
that
in one case, you would POST a Review, say of a book, and in the other 
case, you 
would POST some feedback to the author of the book. In the case of Review, 
the
review would be added to the list of other reviews. Assuming that there 
were a
Web page for the book, it would link to things like: purchase this book, 
as well
as to the list of reviews that had been posted. In the case of the 
feedback document,
the feedback would be sent (possibly via email) to the author.

> 
> <envelope>
>  <body>
>   <m:review>
>    [an-office11-document-goes-here]
>   </m:review>
>  </body>
> </envelope>
> 
> This envelope now has a self-contained meaning, wouldn't you agree?
> Everything you need to understand its application semantics (i.e.
> "review this Office document") is right there.  That's the first sign
> that you're not using POST semantics, because if you were, that envelope
> would mean something different depending upon which method it was
> transferred with; if it were sent with PUT, it would mean "store this
> content", and the document wouldn't be reviewed.

No, in the example I had in mind (it was late as it is now, sorry if the
example wasn't as lucid as it should have been), the URI is the URI of
the book (or whatever) and the review element contains the prose of a 
review
of that book by a critic. Hence, use of POST is IMO quite correct. I am 
creating a subordinate resource of the book.

In the case of feedback, the feedback is some comment by a reader intended
for the author. I see no reason why that couldn't also be a valid use of 
POST
in this case.
> 
> The way I would request review of document with HTTP would be to just
> POST the document to a URI that identifies a resource that reviews
> stuff.

It wasn't a request, it was creating subordinate resources to the one
identified by the URI of the POST request. All very much in accordance 
with
RFC2616 IMO.

The key point is that they are distinct types of subordinate resource and
hence, it would seem logical to me that they might each have their own
processing dependent upon the type of thing in the entity body of the 
POST request. Hence, I've got POST dispatching to separate handlers for 
each
type, based on the QName of the root element of the application/xml entity
body.

Would you agree that that was a valid scenario and completely consistent 
with
the HTTP spec (and RESTful to boot)?

> 
> The hard part is obviously determining *which* URI to POST to.  This
> requires a priori knowledge too, of course; the automaton has to know

I'm not going for a priori in this case. I am trying to get you to agree
that it is a perfectly valid and legitimate use of POST to have it 
dispatch
to separate handlers based on the type of entity body accompanying the 
POST request.

If you agree with that premise, then what possible distinction can you 
make
if the decision is made based on the root element, or based on some 
processing
of the XML document (e.g. parsing all the way into a SOAP message to 
determine
the QName of the child element of the Body)?

I just don't see a distinction. The fact that it happens to match the name
of a method is mere coincidence as far as I am concerned.

> what a "reviewer" resource is so that it can be informed that "this
> URI identifies a reviewer".  Miles and I weren't able to agree that
> this type of a priori knowledge is any different than the a priori
> knowledge required to invoke a "review()" method, so I won't reopen that
> one.  Suffice it to say that this is an alternate means of doing the
> same thing, while respecting the uniform interface constraint.

Again, not going for a priori. We've beaten that horse to death a few
times and I believe that you agreed that it was needed.

> 
> As for "Feedback", since that's a noun, I'm not sure what you had in
> mind by suggesting it.  Because it's a noun, then there is no problem
> since no dispatch action is taken which would change the semantics of
> the HTTP message.  My only issue with that example is that in most
> cases, HTTP messages carry schmema instances, or compound schema
> instances.  In other words, representations of resources or composite
> resources, like a resumé, a set of resumés, or a resumé with an
> embedded picture.  So I would expect "Feedback" would have a whole
> schema available, rather than being a wrapper (unless it was a generic
> wrapper, like you'd need for a set of resumés).  Maybe I'm making a
> mountain of molehill over that, but I wasn't sure what you meant, and I
> wanted to be comprehensive in my response.

Who said anything about a wrapper? I only mentioned that the dispatch 
would
be made based on the QName of the root element.

> 
> Phew!  I hope that was helpful.

Not really because you didn't understand my example... Can we try again?
(Sorry for not making it clearer before... It was certainly clear in my 
head,
just never made it to the electrons making up the ascii characters in my 
note:)

What I am trying to tease out of this discussion is agreement on your part
that there is no reason whatsoever why POST cannot take on different 
processing
based on the content of the message (any aspect of the message... URI, 
entity body,
HTTP headers, etc.)

Given that, why can't this be transitive to methods on an object (or 
class), if that is
what the resource happens to be?

> 
> Cheers,
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Received on Thursday, 9 January 2003 23:13:45 UTC