TL;DR: Rant: When the frontend simply calls backend methods(it's RPC), REST is the wrong choice there. It’s your decision if you still want to use ...
For further actions, you may consider blocking this person and/or reporting abuse
If you want to check other opinions: stackoverflow.com/a/15116562
here is what is written for your convenience:
You really did not read the article. Standardised codes is also laughable point, did AI write this for you ?
You are halucinating points to score on, and giving examples completely out of context. What kind of benefit is there for frontend SPA that intentionally defines same function interface as the server side to mix in HTTP status codes.
I ma not sure that you read the "Scope" section. So many codebases are backend API and something like react with axios layer. The codebase actually has identical method names and parameters ... and to add to htat, it is ususal to keep it consistent for maintenance ... I really see no benefits in your REST pros for that type of appliaction.
I am not gonna bother to elaborate further, you completely missed the use case point.
The comment section of the answer you posted having enough counter arguments for the answer itself. This answer having many upvote does not make it the correct one.
True. Decide for your self :)
Thank you for the article !
TIL about JSON-RPC. For some reason, I never came across this in any codebase I worked on. In hindsight, there were a couple of situations in which it could have been nice to use... I'll definitely keep it in mind.
Your approach is very "purist". Perhaps a bit too much. If REST is the current norm and every developer knows it relatively well, a pragmatic choice would be to avoid introducing new technologies into codebases and stick with something that works and is easily adopted, even if it's not the optimal solution. It's not like we're building software for the sake of building it perfectly. We're paid to build efficiently.
Thanks, this is just my rant, REST feels off so I am personally looking into why I don't like it. I am a proponent of ppl using what they prefer.
I got angry when some fancy auditor came along and made us switch from JSON-RPC to REST, where I had to guess which HTTP methods to use depending on what api does (PUT,GET,DELETE,PATCH,...).
When both ends are just functions that have parameters and some may throw Exceptions, why add that extra burden ? And there is no clear RFC that says clearly. And then as a bonus, for exceptions you also need extra burden of defining different HTTP codes.
That is arguable :D and efficiency means different things to different people. I would argue that adding bloat of REST to situations where communication is clearly RPC is opposite of efficient ;) .
Anyway, If REST is better fit for you, that is absolutely fine. I am glad I could influence you to consider a RPC in the future.
Alas, this is probably one of the greatest curses in the development field.
I must agree with the fact that forcing REST in such a situation is just short-sightedness. Especially given the fact that it was literally adding more work to the pile by rewriting something that's already been implemented to replace it by a more inefficient option.
By the way, you talk about an auditor : was it simply their opinion or instead part of some kind of compliance ruleset ? I wouldn't be shocked to read something like "all public APIs in this branch of the field must be REST-compatible".
no, it was part of auditor's push to use spring the "right way"
Facepalm intensifies
If you thought I was mean, check this linkedin.com/posts/vvoss_thereplac...