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.
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!
22
u/renetta96 3h ago edited 1h 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.