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

While browsing Zhihu, the author encountered the question "Why does the company require all interfaces to use POST?" and reflected on his own experience building a micro‑service from scratch, where he applied common RESTful conventions.

He revisits the fundamental differences between GET and POST:

POST is more secure because parameters are not part of the URL and are not cached or logged.

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

POST supports more data types beyond plain ASCII.

POST is generally slower than GET.

POST is intended for creating or modifying resources; GET is suited for retrieval, sorting, and filtering.

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

From a practical standpoint, the author prefers using GET for simple queries and POST for create, update, delete, or complex queries, rather than enforcing POST universally.

Other contributors criticize the blanket POST rule as catering to low‑skill architects and developers, and some illustrate the point with memes (images omitted).

Adopting a ROI‑oriented view, the author argues that technical choices—including HTTP methods—should serve business goals such as cost‑effective delivery, scalability, stability, and monitoring, rather than being followed dogmatically.

He outlines the genuine benefits of RESTful design:

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

Modeling resources and their relationships.

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

Enabling a uniform interface that tools like Swagger can exploit.

Allowing GET‑based resources to benefit from caching.

However, he also lists the costs of forcing uniformity:

Artificially treating non‑resource concepts as resources, leading to misunderstandings.

Complex path and query‑string handling that hampers monitoring and incident response.

Additional documentation effort even when using Swagger.

Cache management overhead for dynamic endpoints.

Increased front‑end burden due to divergent method and path conventions, requiring translation layers across web, iOS, and Android.

Potential issues with gateway rules that mishandle non‑standard methods.

He concludes that the suitability of a strict POST‑only policy is evident only after real‑world deployment and feedback.

As an example, his current company uses a single dynamic endpoint POST /action with an X-Action header to specify the actual operation, protobuf‑encoded payloads, and a gRPC backend, while static content is served via CDN and GET requests.

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

The article ends with a request for likes, shares, and follows, and promotes the author’s knowledge‑sharing platform, offering paid access to advanced development resources.