Hello.

I am ashamed to admit, but after reading many different articles, I still do not fully understand the difference between PUT and POST

The HTTP 1.1 specification states that PUT
idempotent. This means that the client
can execute many PUT requests
one URI at a time and it won’t result in
creating duplicate records. Operations
assignments are a good example
idempotent operation

String userId =
this.request [“USER_ID”];

Even if this operation is performed
twice or thrice, no harm
will be (except for extra bars
processor). POST on the other hand
not idempotent. It is something like
increment. You should use
POST or PUT considering whether
the action being performed is idempotent or
no. In the language of programmers, if
the client knows the url of the object which
need to be created, use PUT. If
the client knows the url of the method / class
creating the desired object, use
POST.

Here is “a good example of an idempotent String operation userId = this.request [” USER_ID “];”.
What is a good example I don’t understand? What harm can be from this operation if we use POST and not PUT?
I would really appreciate it if you could give me a simple example of where to use PUT and why.

For example, a huge number of services use PUT to download files. How is this justified?

Answer 1, authority 100%

The difference between PUT and POST is a matter of semantics. Since different verbs are used for operations, then their meaning should be different.

Imagine that your service operates in terms of notebook and post. One notebook can contain many entries.

To add a new note to the notebook with the identifier id , you will use the POST method with the URL mydomain / notebooks / id /. Your service, focusing on the POST method, will assign the required record ID by itself, add it to the notepad and return you the URL of the created record (to access the record by GET or to delete it by DELETE). It would be nice to return the URL of the created post to the client.

Let’s say a post with the id post-id has already been created and is available at the URL mydomain / notebooks / id / posts / post-id. But the client (the owner of the post) has fixed a bug in it and wants to overwrite it. To do this, it uses the PUT method with the URL mydomain / notebooks / id / posts / post-id and passes the updated post in the request body. Your service, focusing on the PUT method, deletes the old entry and writes a new one, while it is available at the same URL.

Of course, no one bothers you to always use the POST method (for example, HTML 4 only allowed the GET and POST methods). Still, it is worth adhering to the recommendations in order to ensure a uniform interpretation of the methods by all developers.

Answer 2, authority 41%

As far as I understand all this, then if you compare PUT and POST operations in MySQL, then POST is INSERT, and PUT is UPDATE or INSERT

by KES

Let’s look at the example of a forum. It has threads and messages. We make requests to the hello topic

POST / topic / hello? message = Here
POST / topic / hello? Message = was
POST / topic / hello? Message = Vasya

The first query will create (INSERT ) a hello topic with the message “Here”, the other two queries will also create (INSERT ) new messages in the topic. As a result, we get that the hello theme contains: Vasya was here.

PUT / topic / hello? message = Here
PUT / topic / hello? Message = was
PUT / topic / hello? Message = Vasya

The first query will create (INSERT ) a hello topic with the message “Here”, the other two queries will update (UPDATE ) the message in the topic. As a result, we get that the hello theme contains: Vasya.

The idempotency of PUT here is manifested in the fact that the number of messages in the database during subsequent operations remains unchanged . In terms of links, the sitemap will remain unchanged. Only theme content will be updated.

or: each POST / article / hello request will create a new chapter in the hello article. The first request will create the article itself.

each PUT / article / hello request will update the ONLY chapter in the hello article. The first request will create the article itself.

This is what GET should return to us if we did POST

GET / topic / hello 201
Vasya was here

In this case, these URIs will also be available to us

GET / topic / hello / 1 201
Here
GET / topic / hello / 2 201
was
GET / topic / hello / 3 201
Vasya

This is what GET should return to us if we did PUT

GET / topic / hello 201
Vasya

In this case, we will only have one URI available

GET / topic / hello / 1 201
Vasya
GET / topic / hello / 2 404
GET / topic / hello / 3 404

EXAMPLE # 2 Example with users.

POST / user / eugen? age = 7
POST / user / eugen? Age = 10
POST / user / eugen? Age = 5

Will create 3 users named eugen and age 7, 10, 5, respectively.

PUT / user / eugen? age = 7
PUT / user / eugen? Age = 10
PUT / user / eugen? Age = 5

Only one user named eugen with age 5 will be created

In other words: PUT is obliged to update the record if the data is already there

Hence your example String userId = this.request ["USER_ID"]; storing the value in a variable. No matter how many times you put (PUT ) values ​​into a variable, there will always be one variable.

From here was born EXAMPLE # 3

I don’t know how much this analogy is true, but I think this statement will be true:

POST: push $ variable, value; - as a result, an array of values
PUT: $ variable = value; - as a result, one value

in case of POST, the harm that can occur is that the server memory will overflow. In the case of PUT, there is no harm, only ticks are taken 😉

By the way, I found a good resource on security and idempotency
http://restcookbook.com/HTTP%20Methods/idempotency/

Answer 3, authority 3%

Answer 4, authority 3%

Will create 3 users named eugen and age 7, 10, 5,
respectively.

PUT / user / eugen? age = 7
PUT / user / eugen? Age = 10
PUT / user / eugen? Age = 5

It seems to me that this is not a properly designed Api, Put should be idempotent, but when creating an api it usually returns 201 code, and with Update 200, so. create / update cannot be put.

IMHO

• Post & lt; = & gt; Create / Update
• Put & lt; = & gt; Update

And semantically

PUT / user / eugen? age = 7 – set Eugen to age 7 and how not to create a 7-year-old Eugen.
Then the http response should be either 404 if eugen was not found, or 200 if everything was successfully updated.