Why Some Companies Force All APIs to Use POST – Benefits, Drawbacks, and Better Practices

Background

A company requires every HTTP API to be invoked with POST. The question is why such a uniform policy is adopted.

GET vs POST characteristics

POST does not appear in the URL, so it is not cached, not stored in server logs or browser history, which is considered more secure.

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

POST can transmit arbitrary data types, while GET is limited to ASCII characters.

POST incurs higher latency than GET.

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

GET requests for static resources are cacheable; data‑oriented GET requests are usually not cached.

Technical analysis of a uniform POST policy

Forcing a single method forces non‑resource business concepts to be modeled as resources, which can create misunderstandings and extra communication overhead.

Complex path and query‑string conventions make monitoring and troubleshooting harder, e.g., extracting variable parts from URLs for alerts.

Even with tools like Swagger, documentation is still required; automatic documentation only works well when resources map directly to database tables.

Cache control becomes cumbersome: dynamic endpoints need explicit Cache‑Control: no‑cache or generated ETags, while static content benefits from CDN caching.

Different method and URL structures force front‑end teams to implement translation layers for each client platform, reducing productivity.

Methods other than GET/POST may be stripped by gateway rules, requiring work‑arounds such as method‑override.

RESTful best‑practice arguments

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

Resources are explicitly represented in the URL path.

Additional semantics can be conveyed via query strings, headers, and status codes.

This uniform expression enables tooling such as Swagger to generate and maintain API documentation.

GET resources can be cached at the HTTP layer.

Concrete alternative used in practice

For dynamic business operations the team uses a single endpoint: POST /action Headers:

X-Action: <specific‑action‑name>
Session: <user‑session‑token>
[other tokens / signatures as needed]

The request body contains protobuf‑encoded parameters, which are handed off to a gRPC backend. The endpoint does not provide generic HTTP caching; cache control is handled explicitly by the gateway for static resources (served via CDN) or, if needed, by configuring cache policies per dynamic endpoint.

Conclusion

Whether a uniform POST policy is appropriate depends on the concrete business scenario. Teams should weigh the benefits of method‑level semantics and tooling against the added complexity in monitoring, caching, and front‑end integration before adopting a single‑method API style.