Why Do Some Companies Force All APIs to Use POST? Pros, Cons, and Best Practices

Boot+Cloud project study: macrozheng.com

While browsing Zhihu I encountered an interesting question: "Why does the company require all interfaces to use POST?"

Original question: zhihu.com/question/336797348

When I first saw this, it resonated with me because I had faced a similar situation building a microservice from scratch and applied familiar RESTful conventions.

Re‑examining the differences between GET and POST, I noted:

POST is more secure—it does not appear in URLs, is not cached, and isn’t stored in server logs or browser history.

POST can carry larger payloads (GET has URL length limits).

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

POST is slower than GET.

POST is used for creating or modifying data, while GET is typically for searching, sorting, or filtering.

GET requests for static resources can be cached; data requests are not cached.

From these points, POST shines for large‑payload requests, whereas GET suits static resources and simple queries.

In my own development practice, I use GET for straightforward queries and reserve POST for create, update, delete, or complex queries, rather than forcing every endpoint to be POST.

This open‑source project may be useful: the mall project is a SpringBoot3 + Vue e‑commerce system (GitHub ★60K) with multi‑module backend and Docker/K8S deployment, covering product, order, cart, permissions, coupons, members, payment, etc.

Boot project: https://github.com/macrozheng/mall

Cloud project: https://github.com/macrozheng/mall-swarm

Documentation site: https://www.macrozheng.com

Project demo:

Community Answers

Friend "程墨 Morgan" suggests following industry best practices when defining standards.

Another friend remarked that the policy "accommodates low‑level, unambitious architects and front‑end/back‑end developers".

Another contributor, "大宽宽", proposes discussing the ROI of architectural styles like RESTful and why they are not universally adopted.

Key points include:

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

Leverage the concept of “resource”.

Use URL path, query string, headers, status codes to convey interface functionality.

These conventions enable unified API definitions and tooling such as Swagger.

GET resources can benefit from caching.

But What Is the Cost?

Forcing uniformity can turn non‑resource business concepts into “resources”, causing misunderstandings and communication overhead.

Complex path and query‑string designs make cross‑cutting concerns and monitoring harder.

Even with Swagger, documentation still needs manual effort; benefits diminish for high‑level APIs.

Cache control becomes tricky, requiring explicit headers for dynamic endpoints.

Varying method and path conventions increase front‑end translation layers, reducing developer efficiency.

Non‑GET/POST methods may be blocked by gateway rules, leading to workarounds like method override.

Is It Appropriate?

Ultimately, the suitability is judged by real‑world feedback—complaints and friction reveal mismatches.

While Google S3’s RESTful API works well for storage resources, that does not guarantee the same model fits e‑commerce, social, medical, or enterprise collaboration domains.

If a technical lead creates an API scheme (e.g., all POST) that improves development speed, reduces communication cost, and lowers operational overhead, they are delivering real value.

Conversely, blindly following a book‑prescribed rule without validation can harm the business; such a lead is likened to a “Zhao Kuo”.

In our company, the convention is:

Dynamic business interfaces use a single POST /action endpoint, with an X-Action header specifying the concrete action, session for authentication, and PB‑encoded parameters passed to a gRPC backend. No conventional caching is provided. Static interfaces are served via CDN with multi‑level caching. If a dynamic endpoint needs HTTP‑level caching, it must be explicitly configured at the gateway.

Summary

Readers should reflect on whether their current API standards offer the best cost‑performance trade‑off for their specific business scenario.

Would you design your company’s API spec to require POST for every endpoint, and why?

GitHub ★11K microservice project mall‑swarm offers a complete video tutorial (≈26 hours, 59 lessons) covering the latest microservice stack, Spring Cloud core components, and Kubernetes deployment.

The full video series includes Spring Cloud essentials, microservice hands‑on, and container orchestration, accessible via the provided links.