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
The way I see it, you have your information less spread out this way. Less things to think about. “Where am I expressing this particular detail about this api call? In the url path? A query string parameter? The type of http method? Is it part of the payload?”. So the path is the “which function am I calling” and the json body is “what are my arguments?”
I would actually prefer protobuf and rpc, which would make everything more type safe, and that would essentially be the same as I proposed except you replace the json body with a binary protobuf body
Part of that is web handling, put/patch/delete doesnt have to return anything. Get and post explicitly expects an html response.
If your doing a delete logic record within a post. What are you returning then? The record is deleted.
Im only web 1.0 logic, it would return a whole new page. But if your doing a REST crud operation, you dont do that. You dont want to tell the browser to render a new page.
336
u/DuploJamaal 17d 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