Why Some Companies Force All APIs to Use POST – Pros, Cons, and Real‑World Trade‑offs

When the author first encountered the question on Zhihu—"Why does the company require all interfaces to use POST?"—it reminded them of past experiences applying RESTful conventions while building a microservice from scratch.

Key Differences Between GET and POST

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

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

POST supports more data types, whereas GET is restricted to ASCII characters.

POST is generally slower than GET.

POST is intended for creating, updating, or deleting data; GET is suited for searching, sorting, and filtering.

GET requests for static resources are cacheable, while dynamic data retrieved via GET is typically not cached.

From these points, the author prefers using GET for simple queries and POST for modifications or complex queries, rather than enforcing POST universally.

Community Opinions

One contributor, Morgan, suggests following "industry best practices" when defining API standards. Another humorously claims the rule exists to accommodate "low‑level, unambitious architects and front‑end/back‑end developers."

What Are the Costs of Enforcing POST Everywhere?

Forcing a uniform interface forces business concepts that are not naturally resources to be treated as resources, creating misunderstandings and communication overhead.

Complex path and query‑string constructions make monitoring and troubleshooting harder; distinguishing between 404 caused by deployment issues, missing users, or missing orders becomes painful.

Even with Swagger, additional documentation is still required to convey business semantics, especially when the API does not map cleanly to database tables.

Cache control becomes fragile: dynamic endpoints must explicitly set Cache‑Control: no‑cache or generate ETags, consuming CPU, while static content relies on CDN caching.

Varying HTTP methods and unconventional URL designs force front‑end teams to implement translation layers, reducing developer efficiency across web, iOS, and Android clients.

Non‑GET/POST methods can be stripped by gateway rewrite rules, leading to the need for method‑override work‑arounds.

RESTful Benefits Highlighted

Explicitly expresses business actions via methods (GET, POST, PATCH, PUT, DELETE).

Encourages a resource‑oriented view of the system.

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

Enables uniform tooling such as Swagger for API documentation and maintenance.

Allows GET‑based resources to benefit from HTTP caching.

Author’s Practical Hybrid Solution

In the author’s current company, dynamic business APIs use a single endpoint POST /action with an X-Action header specifying the actual operation. Parameters are protobuf‑encoded in the request body and forwarded to a gRPC backend. No caching is provided except for explicit gateway configuration. Static assets are served via CDN and accessed with GET.

Conclusion

The discussion invites readers to evaluate whether their own API conventions offer the best cost‑performance trade‑off for their specific business context. It asks: if you were designing your company’s API standards, would you mandate POST for everything, and why?