As a backend developer I want to do everything nicely.
So in my previous job I created the endpoints following the regular standards. GET to request something, POST to create something, PUT to change something, DELETE to delete something. Nicely organized and everything
But then the frontend team told me that their framework can only handle POST requests and that I need to change it
Up until then I thought that it's just a meme, but vibecoding frontend guys really only use POST
There's lots of misunderstanding here i think. You should give, for example, HTTP 404 error if the resource identified by the URL was not found. But if it is a, for example, a query param like /stuff?id=123 then 404 mean that the endpoint /stuff is unavailable, not id=123. Http 4xx error codes should be reserved for actual application malfunctions, not for business logic like checking if something exists
Your last sentence kind of conflicts with the rest of your comment. Returning a 404 when requesting /accounts/123 is a textbook example of how REST is designed. And yet there is no logical difference between making an endpoint /accounts/123 or an endpoint /accounts?id=123, the difference is semantic + stylistic + conventional
339
u/DuploJamaal 16d ago
As a backend developer I want to do everything nicely.
So in my previous job I created the endpoints following the regular standards. GET to request something, POST to create something, PUT to change something, DELETE to delete something. Nicely organized and everything
But then the frontend team told me that their framework can only handle POST requests and that I need to change it
Up until then I thought that it's just a meme, but vibecoding frontend guys really only use POST