RE: Summing up on visibility(?)

Just playing devil's advocate for a second.

So you can post some data, but alternatively you can just put it somewhere
so the server can later retieve it and process it. Reminds me of queues: GET
and PUT is all you need.

So you can actually get the same behavior from GET as from POST, which would
make POST redundant if you could pass as much information as you want in
PUT. How much information can you pass in PUT?

Let's say there's a limit. You can pass the local weather report but not a
purchase order. So now you need to do one of two things:

1. PUT some POST some.
2. PUT a reference to the data that could be retrieved with a GET

For no. 1 I would point to the value of a uniform interface. If you can PUT
some POST some, not PUT all but definitely POST all, let's just do POST all
the time. Forget about PUT.

For no. 2 I would point out that now each message passing is actually two
message passing, and instead of just sending data you need to put it
somewhere, identify it, have it retrieved by the "receiver". Pull-based
instead of push. I won't bother to explain which approach seems more
efficient.

arkin

  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Christopher B Ferris
  Sent: Thursday, January 09, 2003 8:13 PM
  To: Mark Baker
  Cc: www-ws-arch@w3.org
  Subject: 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