I said what I said, and I mean every word of it.
For those a little confused, let's back up.
REST (REpresentation State Transfer) APIs are still very common, and honestly I don't have an issue with them for most projects. REST APIs work by using HTTP verbs to denote the purpose of a request, i.e. a
GET request on a given endpoint (say "comments") means that the user is trying to get a list of (or perhaps a specific) comment value(s).
DELETE along with an identifier of some type does just what you think it would: removes the resource given by the identifier. The last two main HTTP methods utilized with REST are
PUT, and this is where I seem to break with most API designers / REST routing libraries.
The last two, in English, are very close to one another due to some extra uses of the word "post", as in to "post a job listing" (i.e. put up, create). For a long time many back-end languages didn't have good support for requests outside of GET or POST (for reasons I honestly don't know), so POST sort of fell as the default for anything that needed more security in sending data (i.e. not transmissible through the URL).
With the growth of AJAX (i.e. XMLHttpRequests) REST APIs became the flavor-of-the-month and with it developers should have thought about our default to using POST requests for creating data / records. Not many did, unfortunately, and many places that use REST APIs have, in my opinion, mixed up PUT and POST.
I read an article some years ago (if I can find it I will link it, but so far have been unsuccessful) stating that the four big verbs (
POST) are really the only verbs you'd need for a large majority of use cases. In that post the author made a point:
POST requests are (in his opinion) for resources that are being modified, not created, because they are POST creation. To create new values, you would PUT data to the server (database).
PUT has always made more sense as the verb for adding new data, but please give me any reasons you may have for thinking that
POST is the preferred method.