[Prev][Next][Index][Thread]

Re: POST vs. separate methods



I've been doing other stuff, so haven't been able to process everything as
fully as I want. However, I've got some comments and I'll mouth off even
thought I'm in arrears for the revised requirements document.

   I think that Yaron has a point about the equivalence of POST w/ content
types, and separate methods, but only when you consider the mechanisms in
isolation from the way things already are. We had about 8-9 messages on the
caching implications of the new update operations, including several
proposals for ways to revise HTTP to handle this kind of
cache-invalidation. I think many of you will agree that this is a
more-general HTTP issue, and should be solved in that context. Given that
assumption, separate methods are a better solution, since they don't
provide any new constaints on the HTTP group: They already have seaprate
methods with update semantics.

   Adding a few more methods to the list will not complicate things in
principle, while if we overload POST we may be creating POST operations
that need special processing that the POST already in place might not be
able to deal with. It also seems to me that the separate method approach is
closer to the original simple OO model behind the WEB, with operations
defined on resources.

   It also seems to me that having content-types for our new operations
like MERGE will make supporting multiple data formats for input to these
operations easier.

   -- David


_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________



Follow-Ups: