I think the importance of the methods name is the convention, the fact that everyone agree on its meaning, semantic correctness goes second in this case; even if your argument is semantically correct it goes against the convention. We have to ask ourselves the cost/benefit of adopting a new approach, in this case the benefit is that is arguably semantically correct (I don't agree, more on that below), the cost is that will confuse the API consumers maybe even generating problems, for me, not worth it. And because is a convention, to avoid confusion almost everyone would have to adopt the change immediately, the longer the change take, more confusion.
I don't agree in the semantic mean of POST, I don't think it refers to later or after, PUT is not PRE after all, POST refers to the verb, the act of posting; we have to consider that the methods are verbs, the use of POST as "after" is not a verb, is a prefix, that mess up everything. Pigs would start to fly, sky would turn green, gravity would turn the other way and earth would actually go flat and hollow.
Well, "POSTing" is simply a synonym for "PUTting up". Like I said, the two words get muddled because English.
If we want to be more technically correct, then really the argument becomes about the poor and forgotten PATCH verb, which I think is more technically in line with updating a resource. The issue is further compounded by the fact that you get slightly different language about PUT, POST and PATCH which muddle the meaning around them.
I agree that convention is largely useful, but sometimes the convention can (and should) be put into question. We can hold no things to be holy, simply because we are told that they are.
POST is like posting an article in a paper, usually don't include the pk in DB, that depends on the implementation on said DB. Is a POST request, in this case the location is not part of the request is up to the receiver of said request.
PUT is the act of just put it there, when you PUT something in some place, location is in fact relevant, putting your hand in the hand of other to greet is very location sensitive, your hand should be in the others hand nowhere else. So the location should be included in the request, the receiver should refuse if the location requested is not available. In case of a DB if the requested pk is already taken or invalid. Is a request to add an entire entry.
PATCH should modify data a registry already in the DB, is for partial modifications of an entry, is different from PUT in that. To use PUT to update is against the convention.
That's how I understand it and makes sense to me, also, language is not always (ironically) literal in the strict sense; CPU is arguably not a unit, container and VM are very abstract and what about cookies, browsers, database, boot, uptime, etc. Technology is too fast, we end up reusing words not designed for it, as I said is a trade off, we should be making new words for new concepts; a screw is not called "rotating nail" nor hammers "heavy things with handles" after all, but imagine the extra mental load to learn thousands of technical new unrelated sets of letters for everything new. The web is not actually a web as we understood it a century ago.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think the importance of the methods name is the convention, the fact that everyone agree on its meaning, semantic correctness goes second in this case; even if your argument is semantically correct it goes against the convention. We have to ask ourselves the cost/benefit of adopting a new approach, in this case the benefit is that is arguably semantically correct (I don't agree, more on that below), the cost is that will confuse the API consumers maybe even generating problems, for me, not worth it. And because is a convention, to avoid confusion almost everyone would have to adopt the change immediately, the longer the change take, more confusion.
I don't agree in the semantic mean of POST, I don't think it refers to later or after, PUT is not PRE after all, POST refers to the verb, the act of posting; we have to consider that the methods are verbs, the use of POST as "after" is not a verb, is a prefix, that mess up everything. Pigs would start to fly, sky would turn green, gravity would turn the other way and earth would actually go flat and hollow.
Well, "POSTing" is simply a synonym for "PUTting up". Like I said, the two words get muddled because English.
If we want to be more technically correct, then really the argument becomes about the poor and forgotten
PATCHverb, which I think is more technically in line with updating a resource. The issue is further compounded by the fact that you get slightly different language aboutPUT,POSTandPATCHwhich muddle the meaning around them.I agree that convention is largely useful, but sometimes the convention can (and should) be put into question. We can hold no things to be holy, simply because we are told that they are.
POST is like posting an article in a paper, usually don't include the pk in DB, that depends on the implementation on said DB. Is a POST request, in this case the location is not part of the request is up to the receiver of said request.
PUT is the act of just put it there, when you PUT something in some place, location is in fact relevant, putting your hand in the hand of other to greet is very location sensitive, your hand should be in the others hand nowhere else. So the location should be included in the request, the receiver should refuse if the location requested is not available. In case of a DB if the requested pk is already taken or invalid. Is a request to add an entire entry.
PATCH should modify data a registry already in the DB, is for partial modifications of an entry, is different from PUT in that. To use PUT to update is against the convention.
That's how I understand it and makes sense to me, also, language is not always (ironically) literal in the strict sense; CPU is arguably not a unit, container and VM are very abstract and what about cookies, browsers, database, boot, uptime, etc. Technology is too fast, we end up reusing words not designed for it, as I said is a trade off, we should be making new words for new concepts; a screw is not called "rotating nail" nor hammers "heavy things with handles" after all, but imagine the extra mental load to learn thousands of technical new unrelated sets of letters for everything new. The web is not actually a web as we understood it a century ago.