On Dec 29, 2004, at 6:47 AM, Josh Sled wrote:
> As per HTTP, POST has two meanings ... "submit data-block for
> data-handling" as well as "resource {creation,annotation,extension}".
> These represent very different designs; I still think it's critical to
> distinguish the two. But, yes, they're "levels of HTTP", not "levels
> of
> REST".

Yes, it was certainly a mistake when the NCSA team introduced HTML
forms processing via POST (which at the time meant the same as NNTP's
post)
without introducing a distinctive method for "process this". However,
we
should also understand why it did not seem important at the time, and
also why it "just doesn't matter" to REST how many meanings are embodied
in HTTP's POST.

visible identifiable
method safe idempotent semantics resource cacheable
-----------------------------------------------------------
GET | X X X X X |
HEAD | X X X X X |
PUT | X X X |
POST(a) | / |
POST(p) | |
OPTIONS | X X X O |
-----------------------------------------------------------

POST(a), as "append this", is unsafe, non-idempotent, non-cacheable,
operates on an unknown resource, and has only minor visibility since
there is no way for an intermediary to anticipate the state of the
resource after the append aside from "some state was added". POST(p),
as "process this", doesn't even have that minor visibility. Thus, an
architectural style like REST can only improve the performance of a
POST-based architecture by finding ways to escape POST (e.g., 201).

Note that POST, regardless of which meaning is being used, has none of
the characteristics that would make it useful for the architecture to
know exactly what is going on. At most, we can obtain an identifiable
resource if the response is 201 and Content-Location, but that is true
of any extension method. That is why it is more efficient in a true
REST-based architecture for there to be a hundred different methods
with distinct (non-duplicating), universal semantics, than it is to
include method semantics within the body of a POST. Inspecting message
bodies to determine message semantics will always be slower than
placing the method up front.

I really should extend the table to include all of the methods that
webdav has added, just to show how disastrous it was to create PROP*
(duplicating semantics) instead of linking to the set of properties
as a separate resource. Maybe someone else has time to add that to the
wiki.

....Roy