Why Some Companies Require All APIs to Use POST: Benefits, Drawbacks, and Design Considerations

While browsing Zhihu, the author encountered a question about why a company mandates POST for every API endpoint, prompting a reflection on HTTP method conventions and RESTful design learned from previous micro‑service projects.

The author revisits the fundamental differences between GET and POST, noting that POST is more secure (not part of the URL, not cached or logged), supports larger payloads, can transmit richer data types, is slower, is intended for modifying resources, and does not benefit from automatic caching of static resources, whereas GET is suited for simple queries and static content retrieval.

In practice, the author recommends using GET for straightforward read‑only queries and reserving POST for create, update, delete, or complex query operations, rather than enforcing POST universally.

Community responses are quoted, ranging from advocating industry best practices to criticizing the policy as catering to low‑skill architects and developers, and questioning the ROI of rigidly applying RESTful conventions.

The discussion expands to the broader business perspective: technical decisions must serve market needs, cost constraints, and system stability. Key backend concerns include understanding business models, ensuring scalability, and maintaining data consistency and monitoring.

RESTful benefits are summarized: expressive HTTP verbs (GET, POST, PATCH, PUT, DELETE), resource‑oriented design, use of URL paths, query strings, headers, and status codes, enabling uniform tooling such as Swagger, and allowing caching for GET resources.

However, the author highlights several costs: forcing non‑resource concepts into a resource model creates communication friction; complex path and query‑string handling hampers monitoring and incident response; documentation still required despite tooling; cache control adds overhead; diverse method usage can confuse front‑end developers; and non‑standard methods may be stripped by gateway rules.

Real‑world implementation details are shared: dynamic business APIs are exposed via a single POST/action endpoint, with the specific action name passed in an X-Action header; authentication and anti‑replay tokens are included; request bodies are protobuf‑encoded and forwarded to a gRPC backend; caching is omitted for dynamic calls. Static assets are served via CDN with GET and appropriate caching.

The author invites readers to evaluate their own API specifications for cost‑effectiveness and suitability, and asks whether they would also enforce POST‑only policies.