Why Some Companies Force All APIs to Use POST – Benefits, Drawbacks, and Best Practices

While browsing Zhihu, the author encountered the question “Why does the company require all interfaces to use POST?” and recalled a past project where RESTful conventions were applied to a microservice from scratch.

He revisits the fundamental differences between GET and POST:

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

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

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

POST is 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 data‑fetching GETs are typically not.

From this comparison, the author notes that POST shines for large or complex requests, while GET remains ideal for simple queries and static resources. In his own work, he uses GET for straightforward queries and reserves POST for mutations, complex queries, or bulk data, rather than forcing POST everywhere.

Community Answers

One contributor, 程墨 Morgan, says he would follow “industry best practices” when defining a standard.

Another participant bluntly remarks that the rule exists to accommodate “low‑level, unambitious architects and front‑end/back‑end developers.”

Beyond the Technical Details – An ROI Viewpoint

The author expands the discussion to business goals: any technical choice ultimately serves market demands, cost constraints, and reliable system delivery. API design is a minor detail compared with larger concerns such as business modeling, system scalability, stability, and monitoring.

Expressing different business actions with distinct HTTP verbs (GET, POST, PATCH, PUT, DELETE, …).

Modeling resources explicitly.

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

Achieving a uniform interface that enables tooling like Swagger.

Allowing GET‑based resources to benefit from caching.

What Are the Costs?

Forcing a uniform POST‑only style makes non‑resource concepts awkward to model, leading to misunderstandings and communication friction.

Complex path and query‑string designs hinder monitoring; variable URLs make it hard to pinpoint the root cause of alerts.

Even with Swagger, documentation is still required because automatic generation only works when the API maps cleanly to underlying data tables or views.

Cache control becomes fragile: dynamic endpoints need explicit Cache‑Control: no‑cache or ETag handling, while static content relies on CDN layers.

Front‑end developers must translate a single POST interface into multiple language‑specific calls, creating extra translation layers for web, iOS, and Android.

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

Is It Appropriate?

The author shares his own company’s practice: dynamic business APIs expose a single endpoint POST /action with an X‑Action header indicating the specific operation, session tokens for authentication, and protobuf‑encoded bodies that integrate with a gRPC backend. These endpoints do not provide conventional caching. Static assets are served via CDN with multi‑level caching and are accessed with GET. If a dynamic endpoint needs HTTP‑level caching, it must be explicitly configured at the gateway.

Conclusion

Readers are encouraged to evaluate whether their current API conventions offer the best cost‑performance trade‑off for their specific business scenario and to consider if a uniform POST policy truly adds value.