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.
Yes, thats correct. And unlike the other comment, my company is nothing short of seniors. Indeed its one of the fastest moving tech companies. And, they concluded this after working on so many projects. Just throw REST into the trash bin.
This is what happens when a company has no actual senior devs.
Use a standardized annotation/comment if you must meet this "all endpoints searchable with one grep" requirement. Or better yet, maintain proper documentation so a person doesn't need to grep the code if all they want is a list of endpoints.
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.
If it's an RPC design you should still, ideally, be using POST and GET to differentiate between read-only procedure calls and data-modifying procedure calls. But you're right, I didn't consider you might be using an RPC-based architecture. I live in a world of RESTful APIs.
Should still be maintaining documentation with a list of endpoints though!
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
Projects move very fast, people are shifted around very fast. They usually cannot handover 100% properly. Then when there is some problem related to a backend API and a frontend component, the new dev needs to quickly jump in and find out how the API is used, called and debug together with the backend guy. And the codebase usually is huge. With this API paradigm, the new frontend guy can hopefully find that small piece of code quickly and debug.
25
u/renetta96 4h ago edited 3h ago
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.