Loading ...
Sorry, an error occurred while loading the content.

4732REST and the design of HTTP methods

Expand Messages
  • Roy T. Fielding
    Dec 29, 2004
      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
      without introducing a distinctive method for "process this". However,
      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

    • Show all 25 messages in this topic