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

Background

While browsing Zhihu the author encountered the question

《公司规定所有接口都用 post 请求，这是为什么？》

. The author reflects on this based on experience building a micro‑service from scratch and applying RESTful conventions.

GET vs POST – Technical Differences

POST does not expose request data in the URL, avoiding caching, server‑log storage, and browser history.

POST can carry a larger payload because GET is limited by URL length.

POST supports binary or non‑ASCII data types; GET is limited to ASCII characters in the query string.

POST generally incurs higher latency than GET.

POST is intended for creating or modifying resources; GET is suited for read‑only operations such as search, sort, and filter.

GET responses for static resources can be cached by browsers, CDNs, or intermediate proxies, whereas dynamic data is usually not cached.

Practical Guidance

Use GET for simple retrievals, static resources, or queries that fit within URL length limits. Use POST for operations that modify state, require large or binary payloads, or involve complex query semantics. A blanket POST‑only rule discards these natural distinctions.

RESTful Considerations

Distinct HTTP methods (GET, POST, PATCH, PUT, DELETE) convey clear business intent.

Modeling APIs around “resources” enables uniform URL structures, query strings, headers, and status codes.

Uniform interfaces allow tooling such as Swagger/OpenAPI to generate documentation and client SDKs automatically.

GET‑able resources can benefit from HTTP caching, reducing load and latency.

Costs of Enforcing a POST‑Only Policy

Semantic loss: business actions are hidden behind a generic POST, making the API harder to understand.

Monitoring and debugging become more difficult because variable path segments and query strings are obscured.

Additional documentation is required to explain business intent, duplicating effort even when Swagger is used.

Cache control becomes cumbersome; dynamic endpoints need explicit Cache‑Control: no‑cache or ETag handling.

Front‑end clients (web, iOS, Android) must implement translation layers to map their logical operations to the generic POST endpoint, reducing productivity.

Non‑standard methods may be blocked by gateway rules, forcing work‑arounds such as method‑override.

Example Mixed Approach Used in Production

In the author’s current system:

Dynamic business actions are exposed via a single endpoint POST /action. The specific action name is supplied in the X‑Action HTTP header.

Authentication, recommendation, anti‑replay, and security tokens are passed in standard headers.

Request parameters are serialized with Protocol Buffers (PB) and placed in the request body, then forwarded to a gRPC backend.

Dynamic endpoints do not rely on HTTP caching; cache control is handled at the gateway or client level when needed.

Static assets are served through a CDN using GET and benefit from multi‑level caching.

Conclusion

Choosing HTTP methods should be driven by the semantics of the operation, payload size, caching needs, and overall system observability. A mixed strategy—using GET for read‑only, cache‑friendly calls and POST for state‑changing or large‑payload requests—generally offers a better cost‑performance trade‑off than a uniform POST‑only policy.

Preserved Code Snippet from Source

最近面试BAT，整理一份面试资料《Java面试BAT通关手册》，覆盖了Java核心技术、JVM、并发、微服务、数据库、数据结构等。