Why Do Some Companies Force All APIs to Use POST? Pros, Cons, and Real‑World Insights

Background

While browsing Zhihu, the author encountered a question titled “Why does the company require all interfaces to use POST?” The author relates this to a past experience building a micro‑service from scratch, where they initially followed standard RESTful conventions.

GET vs POST Comparison

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, while GET is limited by URL length.

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

POST is generally slower than GET.

POST is intended 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 typically are not cached.

From these points, the author concludes that POST excels for large data submissions, while GET is better for static resources and simple queries.

Personal Practice

The author prefers using GET for simple read‑only queries and reserves POST for create, update, delete, or complex queries, rather than enforcing POST for every endpoint as some companies do.

Community Opinions

One contributor, 程墨 Morgan, suggests following industry best practices. Another user sarcastically remarks that the rule exists to accommodate low‑skill architects and developers.

A third comment expands the discussion to ROI, arguing that technical choices should serve business goals. The author lists RESTful advantages:

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

Modeling resources.

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

Enabling uniform tooling such as Swagger.

Allowing caching for GET‑able resources.

Costs of Enforcing POST‑Only

Forcing a uniform style on non‑resource concepts creates misunderstand‑ings and communication overhead.

Complex path and query‑string patterns hinder monitoring and incident response.

Even with Swagger, documentation still needs to be written; benefits appear only when resources map cleanly to database tables.

Cache mismanagement can lead to stale data or extra CPU for ETag generation.

Front‑end developers must translate API calls, reducing productivity across web, iOS, and Android.

Non‑standard methods may be stripped by gateway rules, requiring work‑arounds like method‑override.

Company’s Actual Specification

The author’s current company uses a single dynamic endpoint POST /action. The specific operation is indicated by an X-Action header, with session tokens, anti‑replay tokens, and other security signatures. Parameters are protobuf‑encoded in the request body and forwarded to a gRPC backend. Static assets are served via CDN with GET and caching. If a dynamic endpoint needs HTTP‑level caching, it must be explicitly configured at the gateway.

Conclusion

Readers are encouraged to evaluate whether their API conventions provide the best cost‑performance trade‑off for their specific business context, and to consider if mandating POST for all interfaces truly adds value.