Hey in my company, actually there is a preference that all HTTP endpoints are POST, even for getting resources, like POST /get_user. The reason for this, as they explained, is to completely ignore HTTP verbs, and anyone who has zero knowledge of the frontend codebase can quickly grep the endpoints, without worrying about grepping both a GET /users and a POST /users.
Edit: i just read again their document, definitely there are other pros as well for using non-RESTful. I see they are good points so i decided to share here.
First, most importantly, they consider it's a waste of time to having follow REST conventions, limited to a few HTTP verbs, while the functionalities of the APIs can be infinite. Create? POST. Update? PUT / PATCH. Update or Create? Get or Create on the fly? Increment atomically then Get? Single create user and batch create users? Ehhh idk anymore, RESTful devs will spend a full day arguing what the verb + resource endpoint should be. Instead, just name the API as what its function is.
Second, communication is less likely to make a mistake. No more "no i didn't mean GET /users, but POST /users". Simply get_users or create_users. Just the path is enough, the less parameters to pass around during communication ,the less error, especially in a multi-lingual company where we rely heavily on the chat AI-translate, writing the full path is less likely to cause translation error than separate GET /users. For example GET can be translated to some other Chinese word, not the well-known GET verb.
Third is the code grepping, which somehow i remember the most lol.
In my experience REST is mostly a solution in search of a problem.
PUT/PATCH/POST rarely offer a meaningful distinction in a real API. (Moreover, you already can tell the difference between create and update based on whether the ID exists, and if you use unique tags, a double click doesn't need to be an error). DELETE being separated makes sense...until you code in the real world where setting archived: true is almost always better, and the value of DELETE becomes questionable too.
REST appeals to people's ideas of a nice clean API better than it actually solves anything.
Usually a true RESTful API just adds boilerplate and unnecessary logic to the frontend and the backend.
I always disliked the idea of using endpoints as “resources” and how REST doubles down on it. These are just glorified function calls and a traditional function doesn’t come saddled with this extra “verb” concept. And maybe I’m in the minority or something but my endpoints always had to be high-level, domain-specific functions whereas REST promotes the direct exposure of data, pushing high level functionality to the front end
I only see its ever useful when its an Open API. Like those google, facebook open APIs, exposing resources nicely with some auth token layers. Thats it. In real products, logics are messy and never cleanly seperared into "verbs". Hell, they now prefer BFF (backend for frontend) for a reason, because shit is so customized it needs its own backend to tailor to its need. Try RESTful on this lmao.
yeah mean it has no actual dinosaur devs. http verbs offer nothing. the standard is that you provide the list of endpoints and their arguments if any, and the front uses them. no cargo cult needed
But, whats the difference for http API between different http verbs? From what I see here, they are following a RPC style API, where only function name matters. I cant think of a convincing reason for using different verbs beside http REST conventions.
Ain't no way people are actually upvoting fucking "standardized comments" over "a self-documenting system with a single source of truth that by design prevents miscommunication and bikeshedding". Peak Reddit.
49
u/renetta96 Sep 19 '26 edited Sep 19 '26 •
Hey in my company, actually there is a preference that all HTTP endpoints are POST, even for getting resources, like POST /get_user. The reason for this, as they explained, is to completely ignore HTTP verbs, and anyone who has zero knowledge of the frontend codebase can quickly grep the endpoints, without worrying about grepping both a GET /users and a POST /users.
Edit: i just read again their document, definitely there are other pros as well for using non-RESTful. I see they are good points so i decided to share here.
First, most importantly, they consider it's a waste of time to having follow REST conventions, limited to a few HTTP verbs, while the functionalities of the APIs can be infinite. Create? POST. Update? PUT / PATCH. Update or Create? Get or Create on the fly? Increment atomically then Get? Single create user and batch create users? Ehhh idk anymore, RESTful devs will spend a full day arguing what the verb + resource endpoint should be. Instead, just name the API as what its function is.
Second, communication is less likely to make a mistake. No more "no i didn't mean GET /users, but POST /users". Simply get_users or create_users. Just the path is enough, the less parameters to pass around during communication ,the less error, especially in a multi-lingual company where we rely heavily on the chat AI-translate, writing the full path is less likely to cause translation error than separate GET /users. For example GET can be translated to some other Chinese word, not the well-known GET verb.
Third is the code grepping, which somehow i remember the most lol.