PUT & POST when writing an API

Question

PHP

I was looking for information about the purpose of various HTTP methods, everything is quite logical and obvious except for PUT and POST. The second is considered a general purpose
method , and is perhaps more commonly used. But here's the dilemma, why then use PUT, and does it make sense to use PUT / DELETE instead of a single POST? If DELETE is used to delete - then what is used to create / change? It would be logical to PUT / SET, but the second does not exist. Interested in an authoritative source, or an article by an authoritative author, with an unambiguous answer, in order to meet some, though not officially described, standards.

Answer 1

en.wikipedia.org/wiki/RESTful#RESTful_web_services

Answer 2

Briefly: POST - creation, PUT - update
There will be no authoritative source in relation to REST, since REST, strictly speaking, does not define either POST or PUT. REST simply allows the use of HTTP. Therefore, the most authoritative source on POST/PUT is the HTTP 1.1 specification:
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request- line.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
That is, POST is used to create a subordinate entity, and PUT is used to save an entity.
A POST should always return a status of 201 (Created) and a Location to the new resource if successful.
PUT can return both 201 (if the resource is not found) or 204 (No Content) if the resource has been updated.

Answer 3

A POST request implies the creation of an entry, the result of which should be an empty response body and a location header with the uri of the new object.
PUT - substitution of records. Tobish it is impossible to update one any field at record. Again, if you replaced the object, then you already have all the necessary data on hand, so the location header can again be the answer.
there is also the PATCH method, which allows you to update the record (a specific field or several of them). Here, too, only the URI is meant to be returned. In fact, only a GET request can return any data to you.
And there are a lot of troubles with status codes, they say 200 is good only for GET, since it has a response body. And for most others, you need 204, which says that everything is fine, but there are only headers.
BUT ... this is if according to Feng Shui and exactly RESTFull, and this is far from all. Usually no one goes further than GET / POST / PUT / DELETE ... PATCH is rarely used at all, but LINK has never been used in real projects ...

Answer 4

I recommend that you do not worry too much about the theory, but simply limit yourself to POST and GET. In our project, we did everything according to the rules, and then it turned out that the Flex-code from another server could neither PUT nor DELETE, so we had to do proxying.

Answer 5

Refer to this description: microformats.org/wiki/rest/urls

Answer 6

PUT must be an idempotent operation, i.e. multiple identical consecutive put requests to the same url (and with the same parameters) should not create new objects.
POST, in turn, can create new objects on successive requests to the same URL.
In other words, POST should be used to refer to "producing factories".
First improvised article explaining this: in English .
And yes, PUT can be compared to INSERT… OM DUPLICATE KEY UPDATE.
POST is pure INSERT.

Answer 7

PUT- create a new entry
POST- update an existing entry

Answer 8

1. It seems to me that the most efficient way of working is as follows
GET /reports(.:format) reports#index (collection)
GET /reports/:report_id/images image#index (collection)
POST /reports(.:format) reports# create (creation)
GET /reports/new(.:format) reports#new (initialization, handy technique, can be ignored in terms of REST)
​​GET /reports/:id/edit(.:format) reports#edit (initialization, data for editing)
GET /reports/:id(.:format) reports#show (specific object)
PUT /reports/:id(.:format) reports#update
DELETE /reports/:id(.:format) reports#destroy
DELETE /reports/:report_id/images images#destroy
PUT for collections never had to be used, I won't invent anything
2. The second part of the rest is error codes.
For example, it is effectively used in conjunction with jQuery: success, error, etc. events. respond correctly.
3. (most important) Intersystem interaction.
Restfull API is intuitive for developers of a third-party system, unless, of course, developers understand what rest is
. In any case, when intersystem interaction, it is important to use a single standard, and developing it on the fly is dangerous. Most have chosen REST, if I'm not mistaken.
4. No confusion.
Neither in the application, nor in the frontend, nor in the API, when using REST, you perform the same actions, with the same objects, accessing the same URLs, with the same sets of parameters. The behavior of all systems is predictable, everything is subject to a singleconcepts.