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

While browsing Zhihu, the author encountered the question “Why does the company require all interfaces to use POST?” and reflected on personal experience building a microservice from scratch, recalling RESTful conventions.

Key differences between GET and POST were listed:

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

POST can transmit larger payloads since 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, updating, or deleting data, while GET is suited for searching, sorting, and filtering.

GET requests for static resources can be cached, whereas data‑oriented GETs are not cached.

From these points, the author concludes that POST is advantageous for large or complex requests, while GET remains ideal for simple queries and static resources, and therefore advises against a blanket POST‑only policy.

Community Answers

One respondent, 程墨 Morgan, suggested following industry best practices when defining API standards.

Another user sarcastically remarked that the rule exists to accommodate “low‑level, unambitious architects and front‑end/back‑end developers.”

A deeper discussion considered the ROI of RESTful design, emphasizing that HTTP methods and API conventions ultimately serve business goals such as cost control, scalability, and reliability.

Different HTTP methods (GET, POST, PATCH, PUT, DELETE) express distinct business actions.

Using the resource concept clarifies API intent.

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

A uniform interface enables tooling like Swagger for automatic documentation.

GET‑able resources can benefit from caching.

What Are the Costs?

Forcing uniformity makes non‑resource business concepts awkward, leading to misunderstandings.

Complex paths and query strings complicate monitoring and troubleshooting.

Even with Swagger, manual documentation is still needed; benefits are limited to low‑level APIs.

Cache management becomes error‑prone; dynamic interfaces should avoid caching.

Varied methods and paths increase front‑end translation effort, reducing developer productivity.

Non‑GET/POST methods may be blocked by gateway rules, requiring work‑arounds like method‑override.

Is It Appropriate?

Practical feedback (complaints, debates) reveals whether the rule works in real projects.

While services like Amazon S3 successfully use RESTful APIs for resource storage, such a model does not automatically fit e‑commerce, social, healthcare, or enterprise collaboration systems.

The author’s own company adopts a hybrid approach: dynamic business APIs use a single POST /action endpoint with an X-Action header to specify the operation, PB‑encoded request bodies, and a gRPC backend; static assets are served via CDN and accessed with GET. Cache is applied only where appropriate.

Summary

Readers are encouraged to assess whether their current API conventions provide the best cost‑performance balance for their specific business scenario.

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