Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong>HTTP PUT:</strong></p> <p>PUT puts a file or resource at a specific URI, and exactly at that URI. If there's already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2" rel="noreferrer">idempotent</a>, but paradoxically PUT responses are not cacheable.</p> <p><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6" rel="noreferrer">HTTP 1.1 RFC location for PUT</a></p> <p><strong>HTTP POST:</strong> </p> <p>POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2" rel="noreferrer">idempotent</a>, however POST responses <em>are</em> cacheable so long as the server sets the appropriate Cache-Control and Expires headers.</p> <p>The official HTTP RFC specifies POST to be:</p> <ul> <li>Annotation of existing resources;</li> <li>Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;</li> <li>Providing a block of data, such as the result of submitting a form, to a data-handling process;</li> <li>Extending a database through an append operation. </li> </ul> <p><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5" rel="noreferrer">HTTP 1.1 RFC location for POST</a></p> <p><strong>Difference between POST and PUT:</strong></p> <p>The RFC itself explains the core difference:</p> <blockquote> <p>The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.</p> </blockquote> <p><strong>Using the right method, unrelated aside:</strong></p> <p>One benefit of <a href="http://en.wikipedia.org/wiki/Resource_oriented_architecture" rel="noreferrer">REST ROA</a> vs SOAP is that when using HTTP REST ROA, it encourages the proper usage of the HTTP verbs/methods. So for example you would only use PUT when you want to create a resource at that exact location. And you would never use GET to create or modify a resource.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload