From: Jeff Bone (jbone@clickfeed.com)
Date: Thu Mar 16 2000 - 09:47:02 PST
Okay, let me see if I can recover somewhat from this train wreck.
(1) Mark's (and other's) point is that we shouldn't pollute the semantics of GET. GET
should be idempotent and non-parameterized; its semantics should mean "give me a
representation of the named object." This is entirely reasonable, and necessary to
practically support architectural requirements like caching / object-level routing.
(2) My point was originally that you can build a "complete" protocol with just a
single method --- call it GET, POST, INVOKE, or what have you --- that has RPC-like
semantics, i.e. names a "responder," takes parameters, returns results in some
arbitrary data format. My bad for using these terms almost interchangeably in certain
parts of my rant.
(3) While you *could* simply simulate idempotent GET over this POST / INVOKE /
whatever, you would still want / need to have defined a standard name for that
operation in order to facilitate caching. Fine, but for the academic purposes of the
discussion, let's be clear that this is an *optimization* and it's really not a big
deal whether this is supported in the protocol per-se or in the
protocol-over-the-protocol. But there's at least a reasonable argument for having both
idempotent / 0-ary GET and non-idempotent N-ary POST / INVOKE.
(4) If you've got POST / INVOKE, you've essentially got RPC. I don't understand
Mark's very vigorous anti-RPC stance; this confusion plus my own playing fast and
loose with terminology through these three or so separate argument threads may have
really obscured the conversation. Mark, are you saying that parameterized POST /
INVOKE is considered harmful? Or are you saying that POST is sufficient without any
further request / response data format or syntax on top?
(5) If Mark is saying that POST / INVOKE is considered harmful, well, that seems like
a really wacky and not very pragmatic viewpoint to me. If Mark is saying that POST is
sufficient without any further request / response syntax, I'm not sure I agree. The
benefit of e.g. XML-RPC is that it provides a common data format / syntax for requests
and reponses.
(6) We at least all seem to agree to some extent that adding new methods into HTTP,
for the most part --- i.e., adding application-specific methods and semantics on par
with GET / POST --- is mostly undesirable.
Does that summarize in slightly clearer, more concise fashion?
jb
This archive was generated by hypermail 2b29 : Thu Mar 16 2000 - 09:47:14 PST