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

When the author encountered a Zhihu question asking why a company mandates all interfaces to use POST, he reflected on his own experience building a microservice and revisited the fundamental differences between GET and POST.

POST is more secure because it is not part of the URL, so it is not cached, logged in server logs, or stored in browser history.

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

POST supports more data types, while GET can only transmit ASCII characters.

POST is slower than GET.

POST is intended for creating, updating, or deleting data; GET is typically used for searching, sorting, or filtering.

GET requests for static resources are cacheable, whereas data‑retrieval GET requests are not.

From these points, the author concludes that POST shines for large data submissions, while GET is better for static resources and simple queries. He personally uses GET for simple reads and POST for all other actions, rather than forcing POST everywhere.

Community Answers

One contributor, 程墨 Morgan, suggested following "industry best practices" when defining API conventions.

Another user sarcastically remarked that the policy exists to accommodate low‑skill architects and developers.

Why RESTful Matters

From an ROI perspective, the author argues that any technical choice, including HTTP methods, ultimately serves business goals such as cost‑effective delivery, scalability, stability, and monitoring.

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

Leverage the concept of “resources”.

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

These conventions enable a unified API style that tools like Swagger can automate.

GET‑able resources can benefit from caching.

What’s the Cost?

Forcing uniformity makes non‑resource business concepts awkward to model, leading to misunderstandings and communication overhead.

Complex path and query‑string constructions hinder cross‑cutting concerns such as monitoring and alerting.

Even with Swagger, documentation is still required; the tool only helps when API resources map cleanly to database tables or views.

Cache misuse can cause stale data; dynamic APIs need explicit no‑cache headers or ETag generation, adding CPU cost.

Varying method and URL designs force front‑end teams to build translation layers for web, iOS, and Android, reducing productivity.

Non‑standard methods may be stripped by gateway rules, leading to workarounds like method‑override.

Is It Suitable?

The author notes that real suitability is revealed by developer feedback during implementation. He cites Google S3 as a successful RESTful example because it naturally deals with “resources”. However, that does not prove RESTful is optimal for e‑commerce, social media, healthcare, or enterprise collaboration.

If a technical lead creates an API scheme (even a POST‑only one) that improves development speed, reduces communication friction, and lowers operational costs, the company benefits through higher revenue and employee compensation. Conversely, blindly following a textbook rule without validation can harm the business.

In the author’s own company, the convention is:

Dynamic business APIs use a single endpoint POST /action with an X-Action header specifying the actual operation, session tokens for authentication, and protobuf‑encoded payloads that integrate with a gRPC backend. No caching is provided except for idempotency protection.

Static assets are served via CDN with multi‑level caching and accessed with GET.

If a dynamic API 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.

Would you design a company‑wide API rule that forces every endpoint to use POST? Why or why not?