Home/ Questions/Q 1043961
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T15:45:04+00:00

While looking at the code in petclinic, part of Spring 3.0 samples I noticed

  • 0

While looking at the code in “petclinic”, part of Spring 3.0 samples I noticed the following lines 

<c:choose>
  <c:when test="${owner.new}"><c:set var="method" value="post"/></c:when>
  <c:otherwise><c:set var="method" value="put"/></c:otherwise>
</c:choose>

In this discussion at SO it seems that PUT should be used for “create/update” and POST for “updates”.

Which is right?

What is the impact of using post for “create” and put for “update”?

Note : According to the HTTP/1.1 spec. quoted in the referenced SO discussion, the code given above seems to have the correct behavior.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Both POST and PUT are have well defined behavior as per HTTP spec.

    The result of a POST request should be a new resource that is subordinate to the request URL; the response should contain Location header with the URL of the newly created resource.

    The result of a PUT should be an update of the resource at the request URL. if there is no existing resource at the request URL, a new one can be created.

    The confusion arises from the fact that POST is also used with forms as a mechanism to pass the form data. Most common implementation of forms is to post back to the same URL at which the form page is located, thus giving the false idea that the POST operation is used for an update. However, in this particular usage, the form page is not the resource.

    With all this in mind, here’s the correct (in my opinion of course :-)) usage:

    POST should be used to create new resources when:
    – the new resource is subordinate to an existing resource
    – the resource identity/URL is not known at creation time

    PUT should be used to update existing resources with well-known URL. It can be used to create a resource at well-known URL as well; however, it does help to think about this scenario in a different way – if the resource URL is known before the PUT request is made, this could be treated the same as the resource at this location already existing but being empty.

    • 0