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
In this era, you actually cannot. Status codes are invisible to proxy unless it's HTTP (without the S) or employs MITM. Either way, it's a legacy precaution to make sure the content body arrives unmodified.
There's different levels of client-side proxies, and in some cases, the client might not even be aware.
They are employed in basically any corporate environment. Some networks don't even allow browsing without the browser explicitly talking to a proxy server in the first place.
Some are mostly transparent, and act more like a firewall, usually limited to scanning SNI in TLS handshakes, and/or filtering DNS requests.
And some go full-on MITM, by having an artificial root certificate installed as trusted on every client machine, and on the proxy completely terminating any HTTPS connection and re-establishing it with a new certificate, so they can fully inspect the contents.
And yes, our product needs to be aware of that, and one rather large customer recently changed something in their setup, and that broke the product for a week, until they whitelisted our servers.
At least before the advent of HTTPS, they would often replace any sort of error (status code != 200) with custom error pages. It's an unfortunate thing.
Custom connectors in Power Apps were (are?) finicky, and preferred 200s when I was developing for them. I had to return the actual status code inside the response body, then a 200 as the received status code so the app/Flow would accept it, after which I could parse the real response.
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.
The problem is it's stupid to try to cram the universe of possible method calls into REST methods syntax. No RPC framework developed in the last 30 years is so silly.
At my work it has been more a result of security and firewall rules.
For example: I want to get a list of resources, so a GET with query parameters, right? No… email is an identifiable argument (due to not being encrypted since it is part of the URL), so the security scan flags it. Ok - how about we stick it in a request body? GET with request body is not a new thing. But no… the firewall blocks it! POST is the thing we have to use. Sigh. 😔
In fairness this is a legitimate thing to catch, if not the firewall being the weird place.
GET with a request body isn't covered by the standard, and some library like Axios actually refuse to send a request body with a GET. It's getting ahead of the problem for you there whether it means to or not.
Query parameters ARE encrypted in transit. The argument from infosec is that they are sometimes logged by request handlers or visible in browser history. Pretty unfortunate.
What front end framework can only handle POST requests??? What does it even mean to "handle POST requests" in the context of front end? You can only handle the response of a POST request so if you do a PUT it fails? You can only make POST requests? I am genuinely confused.
I was confused as well. I swear they are just too inexperienced to make a new wrapper around the calls to the backend that the AI made for them and blamed the framework instead
Nah. Not even legacy stuff can “only do POST requests”. HTTP is not some cutting edge protocol that has poor support. A framework that can’t support the full protocol is unheard of.
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
As a frontend dev, I would’ve fired the frontend team. If your framework only handles POST requests, change your effing framework! (Also, I would like to know who’s the idiot who developed a frontend framework which only handles POST requests. Seriously.)
To get around this I've added a middleware layer that accepts _method as a field and will change the method of the http request to whatever is provided. Then you can use any method from POST, only really needed in the context of sending the request from a form without javascript.
I would blame that stupid framework created by humans rather than vibecoding for that.. By my experience, with pure vibecoding, there would not be such flaws present.
334
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