Why Some Companies Force All APIs to Use POST – Pros, Cons, and Best Practices

When I first encountered the Zhihu question about why some companies require all interfaces to use POST, I recalled a 2019 project where I built a microservice from scratch and applied common RESTful conventions.

Revisiting the topic, I compared the differences between GET and POST requests:

POST is safer because its parameters are not part of the URL, so they are not cached, logged in server logs, or stored in browser history.

POST can carry larger payloads; GET URLs have length limits.

POST supports more data types, while GET is limited to ASCII characters.

POST is slower than GET.

POST is used for creating or modifying data; GET is typically used for searching, sorting, and filtering.

GET requests for static resources may be cached, whereas data requests are not.

From these points, POST is advantageous for requests with large data, while GET suits static resources and simple queries.

I usually use GET for simple query endpoints and POST for create, update, delete, or complex queries, but I would not enforce POST for every API as the original company does.

One netizen, 程墨Morgan, suggested following industry best practices when defining standards.

Another comment argued that such a rule accommodates low‑level, unambitious architects and developers.

If you were designing your company's API specification, would you mandate that all interfaces use POST, and why?