PUT vs POST difference as a computer network and internet technology student

[blueberry123]

 I am not a web developer or anything professional. I am just a student learning topic called HTTP protocol. In which I got confused by PUT vs POST methods. This is probably not even 1 marks stuffs in most exams (unless we are explicitly asked about HTTP methods where it can weigh upto 2.5+2.5=5 marks as the maximum marks that can be asked from this topic is 10 marks and we would be expected to write 4 of the methods).

What's that all I need to know about this?
I did a huge research for learning this. Mostly I stumbled upon stackoverflow. Most online sites have copied pasted the stackoverflow answer. I haven't read the HTTP RFC as I feel

a) I am not at that caliber to read and understand RFC yet. I prefer reading books written by authors who simplify those RFCs.

b) I don't feel I should do this all for a subtopic(if my luck is bad, we could get asked HTTP methods for 10 marks in exam lol, hope i don't get jinxed).

But I have read MDN docs about them, but really speaking, they added no value to my learning. Maybe that is great for web developers but as a computer science student, that really didn't make lots of sense.

So till now I have collected this much information-:

1) PUT and POST both are same thing logically. It is just that one is used for sth and another for sth just for convention.

2)PUT write documents to server. It can create new documents in specified URL or if document already exists in that URL, it can replace its contents. Whereas POST is used to send input data to server rather than some random document data.





So the difference could be in type of data sent. One sends data to store in server only, whereas other sends data to query the server for other data.

3)PUT for update in CRUD, and POST for create in CRUD.

4) PUT-: I just want data to be created at this location. Or data to be updated if it already exists.
POST-: I just want data to be sent to this location.

5)PUT displays data to be sent in URL. POST doesn't. So PUT is used in google search, google maps, whereas POST is used in forms data.

6)PUT is idempotent meaning doing PUT 1000 times will have the same result as doing PUT 1 time.

This is all I have learnt. While I know whatever I have learnt is all correct and well. I want few things from the users of this website.
1) A simple definition that can explain PUT and POST.

If possible, extra explanations to solidify my concept.

Figure for explanations of PUT and POST-:

https://i.stack.imgur.com/nbHen.png

https://i.stack.imgur.com/iNS2T.png

[icecream-guy]

The POST verb is most-often utilized to **create** new resources. In particular, it's used to create subordinate resources. That is, subordinate to some other (e.g. parent) resource. In other words, when creating a new resource, POST to the parent and the service takes care of associating the new resource with the parent, assigning an ID (new resource URI), etc.

On successful creation, return HTTP status 201, returning a Location header with a link to the newly-created resource with the 201 HTTP status.

POST is neither safe nor idempotent. It is therefore recommended for non-idempotent resource requests. Making two identical POST requests will most-likely result in two resources containing the same information.

Examples:

POST http://www.example.com/customers
POST http://www.example.com/customers/12345/orders

==
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.

PUT is not a safe operation, in that it modifies (or creates) state on the server, but it is idempotent. In other words, if you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call.

If, for instance, calling PUT on a resource increments a counter within the resource, the call is no longer idempotent. Sometimes that happens and it may be enough to document that the call is not idempotent. However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests.

Examples:

PUT http://www.example.com/customers/12345
PUT http://www.example.com/customers/12345/orders/98765
PUT http://www.example.com/buckets/secret_stuff


--
ref
https://www.restapitutorial.com/lessons/httpmethods.html#:~:text=The%20primary%20or%20most%2Dcommonly,but%20are%20utilized%20less%20frequently.

[deanwebb]

Reading the RFC slowly and deliberately is the best way to read the RFC. It can be done and often should be done.

There is also the TCP Handbook, an EXCELLENT resource: http://www.tcpipguide.com/free/t_HTTPMethods.htm

4 pages on the topic, very well written.