Re: POST in REST

> Jeff Bone wrote:
> > GET:  someprog < foo
> > PUT:  somestuff > foo
> > DELETE:  rm foo
> > POST:  somestuff >> foo
> 
> I've always said:
> 
> GET: cat foo
> (or if CGI: ./foo --arg1=val1 --arg2=val2 ...)
> PUT: cat > foo
> DELETE: rm foo
> POST: cat | foo

If I squint and wave my hands, that works, but looking more closely
this approach constrains foo to be both end-user content and
system-executable content.   I think we need to change POST to be be
more like
   POST: cat | .post-handler-for-foo
or
   POST: cat > foo.fifo

That is, POST talks to some process which is associate with foo, but
not in so simple a manner as being the foo, itself, running.  

What's more, this approach of talk-to-the-man-behind-the-curtain
breaks the very-useful illusion of a space filled with linked
documents.  How should Google index things-you-POST-to?  They're
really very different things from web pages.

My current theory is that POST is the way to create a new web page,
and the data you post is the data for the page.  Whether the page
lasts more than a nanosecond, and whether it every becomes public, are
beside the point.  POSTing is handing a peice of paper to the guy
running the bulletin board; he might look at it and throw it away, he
might put in in a private section of the board for a while, or he
might put it up on the board with everything else.  The essential
points are (1) you hand it to the guy in charge of some particular
slip already on the board, and (2) it's a peice of paper like the
stuff on the board, but with no actual location on the board yet.

    -- sandro

Received on Monday, 2 December 2002 15:55:19 UTC