From c89e31f3c196e2b9a9f9d02d6332794ec8acac5a Mon Sep 17 00:00:00 2001 From: Flolagale Date: Sun, 11 Nov 2012 15:16:29 +0100 Subject: [PATCH] Fix typo. The 'request' word was written twice in the PUT verb description. --- lessons/httpmethods.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lessons/httpmethods.html b/lessons/httpmethods.html index 90ed1f0..ed972db 100644 --- a/lessons/httpmethods.html +++ b/lessons/httpmethods.html @@ -109,7 +109,7 @@
-

PUT is most-often utilized for update capabilities, PUT-ing to a known resource URI with the request request body containing the newly-updated representation of the original resource.

+

PUT is most-often utilized for update capabilities, PUT-ing to a known resource URI with the request body containing the newly-updated representation of the original resource.

However, PUT can also be used to create a resource in the case where the resource ID is chosen by the client instead of by the server. In other words, if the PUT is to a URI that contains the value of a non-existent resource ID. Again, the request body contains a resource representation. Many feel this is convoluted and confusing. Consequently, this method of creation should be used sparingly, if at all.

Alternatively, use POST to create new resources and provide the client-defined ID in the body representation—presumably to a URI that doesn't include the ID of the resource (see POST below).

On successful update, return 200 (or 204 if not returning any content in the body) from a PUT. If using PUT for create, return HTTP status 201 on successful creation. A body in the response is optional—providing one consumes more bandwidth. It is not necessary to return a link via a Location header in the creation case since the client already set the resource ID.