Ignore:
Timestamp:
Jan 6, 2013, 11:45:18 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) update description of PUT

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2096 r2097  
    14331433<t>
    14341434   The fundamental difference between the POST and PUT methods is
    1435    highlighted by the different intent for the target resource.
     1435   highlighted by the different intent for the enclosed representation.
    14361436   The target resource in a POST request is intended to handle the
    1437    enclosed representation as a data-accepting process, such as for
    1438    a gateway to some other protocol or a document that accepts annotations.
    1439    In contrast, the target resource in a PUT request is intended to
    1440    take the enclosed representation as a new or replacement value.
    1441    Hence, the intent of PUT is idempotent and visible to intermediaries,
    1442    even though the exact effect is only known by the origin server.
    1443 </t>
    1444 <t>
    1445    Proper interpretation of a PUT request presumes that the user agent
    1446    knows what target resource is desired.  A service that is intended
    1447    to select a proper URI on behalf of the client, after receiving
    1448    a state-changing request, &SHOULD; be implemented using the POST
    1449    method rather than PUT.  If the origin server will not make the
    1450    requested PUT state change to the target resource and instead
    1451    wishes to have it applied to a different resource, such as when the
    1452    resource has been moved to a different URI, then the origin server
    1453    &MUST; send an appropriate <x:ref>3xx (Redirection)</x:ref> response;
    1454    the user agent &MAY; then make its own decision regarding whether or not to
     1437   enclosed representation according to the resource's own semantics,
     1438   whereas the enclosed representation in a PUT request is defined as
     1439   replacing the state of the target resource. Hence, the intent of PUT is
     1440   idempotent and visible to intermediaries, even though the exact effect is
     1441   only known by the origin server.
     1442</t>
     1443<t>
     1444   Proper interpretation of a PUT request presumes that the user agent knows
     1445   which target resource is desired. A service that selects a proper URI on
     1446   behalf of the client, after receiving a state-changing request, &SHOULD; be
     1447   implemented using the POST method rather than PUT. If the origin server
     1448   will not make the requested PUT state change to the target resource and
     1449   instead wishes to have it applied to a different resource, such as when the
     1450   resource has been moved to a different URI, then the origin server &MUST;
     1451   send an appropriate <x:ref>3xx (Redirection)</x:ref> response; the
     1452   user agent &MAY; then make its own decision regarding whether or not to
    14551453   redirect the request.
    14561454</t>
Note: See TracChangeset for help on using the changeset viewer.