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

While browsing Zhihu, I encountered the question

《公司规定所有接口都用 post 请求，这是为什么？》

, which sparked my own reflections on API method choices based on past experience building micro‑services.

Original question: zhihu.com/question/336797348

Below are key differences between GET and POST that I recalled:

POST is more secure because parameters are not part of the URL, avoiding caching, server logs, and browser history.

POST can carry larger payloads; GET is limited by URL length.

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

POST is generally slower than GET.

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

GET requests for static resources can be cached, whereas data‑retrieval GETs are typically not cached.

From these points, POST shines for large data submissions, while GET is better for static resources and simple queries.

In my own development practice, I use GET for straightforward queries and reserve POST for create, update, delete, or complex queries, rather than enforcing POST universally.

One contributor, 程墨 Morgan, suggested following industry best practices, while another remarked that such a rule merely accommodates low‑skill architects and developers.

Expanding beyond the method debate, I considered the ROI of strict RESTful conventions. Ultimately, technical choices serve business goals: delivering value within acceptable cost, ensuring scalability, stability, and observability.

Key benefits of adhering to RESTful principles include:

Expressing distinct business actions via methods like GET, POST, PATCH, PUT, DELETE.

Modeling resources explicitly.

Leveraging URL paths, query strings, headers, and status codes to convey functionality.

Enabling uniform tooling such as Swagger for API documentation.

Allowing GET‑based caching for resources.

However, forcing a single method can incur costs:

Forcing non‑resource concepts into a resource model creates misunderstandings and communication friction.

Complex path and query‑string designs hinder monitoring and troubleshooting.

Even with Swagger, documentation still requires effort; benefits diminish for high‑level APIs.

Cache management becomes error‑prone, especially when distinguishing dynamic from static endpoints.

Multiple front‑end platforms (web, iOS, Android) may need translation layers, reducing developer efficiency.

Non‑standard methods can be stripped by gateway rules, leading to workarounds like method‑override.

In practice, my company adopts a pragmatic approach: dynamic business APIs use a single POST endpoint /action with an X-Action header to specify the operation, PB‑encoded payloads, and gRPC integration; static assets are served via CDN with GET and caching. This balances development speed, operational simplicity, and performance.

Readers are encouraged to evaluate whether their current API conventions offer the best cost‑performance trade‑off for their specific business context.