PUT and POST - are they implementation dependent?

Question

I'm developing Spring Rest webs service using PUT and POST

@RequestMapping(value = "/test", method = RequestMethod.POST)
@Override
public String function(Model model)
{
}

So, what is the difference between using PUT and POST in this case?

I know that PUT is idempotent, meaning if the same url is called multiple times, the effect should be the same. If I provide the request method as PUT and if I include a DB operation inside the function, won't the meaning of PUT change, meaning if I call the test url multiple times, the DB value will change each time.

My question is does the idempotence, state change, all those features depend on the developer's implementation?

Better example:

@RequestMapping(value = "/test", method=RequestMethod.POST, produces={"application/json"})
public @ResponseBody List<Integer> postData(@RequestParam String name) {        

    if (name.equalsIgnoreCase("okkk")) {
        return returnDataList();
    }else {
        List<Integer> list = new ArrayList<Integer>();
        list.add(12345);
        return list;
    }
}

@RequestMapping(value = "/test/{name}", method=RequestMethod.PUT, produces={"application/json"})
public @ResponseBody List<Integer> putData(@PathVariable String name) {     

    if (name.equalsIgnoreCase("okkk")) {
        return returnDataList();
    }else {
        List<Integer> list = new ArrayList<Integer>();
        list.add(12345);
        return list;
    }

Both the methods are the same, I believe. I just put PUT and POST, a little confused.

zachbugay · Accepted Answer · 2017-10-11T20:22:39.130

3

Here is the best answer regarding this: What's the difference between a POST and a PUT HTTP REQUEST?

No matter how many times PUT is called it should do exactly the same thing over and over again. PUT responses are not cacheable.

POST allows the web server to decide what to do with the data. These requests can be cached, assuming "the server sets the appropriate Cache-Control and Expires Headers."

There is another resource that I believe can be helpful: PUT vs. POST in REST

The author sums up there very nicely when to use a POST and when to use a PUT. I have selected what should be the most simplistic:

POST: Used to modify and update a resource.

PUT: Used to create a resource, or overwrite it.

edited Oct 11 '17 at 20:22

answered Oct 11 '17 at 19:07

zachbugay

704
1
9
21

"No matter how many times PUT is called it should do exactly the same thing over and over again. PUT responses are not cacheable" meaning, if i use PUT for a DB operation,it should onl;y update once ? – Parameswar Oct 11 '17 at 19:10
You can technically do whatever you want with PUT, POST, GET, etc. So if you wanted to write PUT to actually return a list of items, you could do that if you wanted to. If you do that though you're not following RESTful implementations. – zachbugay Oct 11 '17 at 19:12
added one example, can you please check ? – Parameswar Oct 11 '17 at 19:25
@parameswar I updated my answer. Let me know if this is helpful or not. – zachbugay Oct 11 '17 at 20:23

score 1 · Answer 2 · edited Nov 26 '18 at 09:35

As far I understood beside the conceptual difference and REST guidelines, PUT is idempotent => a client API is expecting the same result no matter how many times he calls the webapi PUT method, but as webapi developer you can do whatever you want, there is no technical limitation between PUT and POST (beside URL parameter)...

So if I have the same code in POST and PUT the webapi behave the same? I did not notice any difference:

public Person Put(int id, [FromBody]Person person)
{
    Person dbPerson = Persons.Find((x) => x.Id == id);
    if (dbPerson != null)
    {
        dbPerson = person;
    }
    else
    {
        Persons.Add(dbPerson);
    }
    return dbPerson;
}

and

public Person Post([FromBody]Person person)
{
    Person dbPerson = Persons.Find((x) => x.Id == person.Id);
    if (dbPerson != null)
    {
        dbPerson = person;
    }
    else
    {
        Persons.Add(dbPerson);
    }
    return dbPerson;
}

score 0 · Answer 3 · answered Oct 11 '17 at 22:08

Does the idempotence, state change, all those features depend on the developer's implementation?

Yes, it is up to the developer to implement PUT and POST in a way that meets the HTTP specification. If you fail to do that, your service will probably still work but there is a small chance that you will encounter unexpected problems (e.g. your service might behave weirdly when accessed from behind a proxy).

If I include a DB operation inside the function, won't the meaning of PUT change?

You can perform database operations when you handle a PUT request as long as the effect is idempotent.

For example, if your service lets clients create files using requests such as PUT /myfile with the desired content passed in the body, you could handle each request using a database transaction that does the following:

Check if the named file already exists
If it already exists, update its content and respond with 200 (OK)
Otherwise, create the file and respond with 201 (Created)

This is idempotent, because if the same request is made a second time the state of the database will not change.

For a non-idempotent example, suppose step 2 was changed to the following:

If it already exists, append the new content to the existing content

This is not idempotent, because if a client sends the same request twice the file will have two copies of the content.

PUT and POST - are they implementation dependent?

3 Answers3