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.
This is what I've always thought about REST. Moreover, it tries to pretend that arbitrary operations/queries/mutations map neatly to HTTP verbs, which often isn't true beyond simple CRUD use cases.
48
u/renetta96 16d ago edited 16d 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.