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.html

    r2096 r2097  
    14751475         the server.
    14761476      </p>
    1477       <p id="rfc.section.4.3.4.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the target resource.
    1478          The target resource in a POST request is intended to handle the enclosed representation as a data-accepting process, such
    1479          as for a gateway to some other protocol or a document that accepts annotations. In contrast, the target resource in a PUT
    1480          request is intended to take the enclosed representation as a new or replacement value. Hence, the intent of PUT is idempotent
    1481          and visible to intermediaries, even though the exact effect is only known by the origin server.
    1482       </p>
    1483       <p id="rfc.section.4.3.4.p.8">Proper interpretation of a PUT request presumes that the user agent knows what target resource is desired. A service that
    1484          is intended to select a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
     1477      <p id="rfc.section.4.3.4.p.7">The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation.
     1478         The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics,
     1479         whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the
     1480         intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
     1481      </p>
     1482      <p id="rfc.section.4.3.4.p.8">Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that
     1483         selects a proper URI on behalf of the client, after receiving a state-changing request, <em class="bcp14">SHOULD</em> be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to
    14851484         the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved
    14861485         to a different URI, then the origin server <em class="bcp14">MUST</em> send an appropriate <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
Note: See TracChangeset for help on using the changeset viewer.