Why Some Companies Use POST for All APIs: A Practical Look at GET vs POST

In a recent discussion the author reflects on a common corporate rule that forces all HTTP interfaces to use POST, sharing personal experience from building a micro‑service and recalling RESTful conventions.

The core differences between GET and POST are listed:

POST is more secure because parameters are not part of the URL and are not cached or logged.

POST can carry larger payloads, bypassing URL length limits.

POST supports more data types beyond plain ASCII.

POST is generally slower than GET.

POST is intended for creating or modifying resources, while GET is suited for queries and static retrieval.

GET requests for static resources can be cached, whereas data‑driven GET requests are typically not.

Several community comments are quoted, offering viewpoints ranging from practical best‑practice recommendations to criticism of over‑standardisation.

The author argues that a blanket POST rule can increase development cost, complicate monitoring, and hinder front‑end consumption, especially when multiple client platforms need to translate the same call.

Potential drawbacks of strict RESTful uniformity are enumerated, such as forced abstraction of business concepts into resources, difficulty in path‑based monitoring, extra documentation overhead, cache mismanagement, and the need for method‑override work‑arounds.

Finally, the article suggests evaluating whether a company’s API conventions truly deliver cost‑effectiveness and alignment with business goals, and encourages readers to consider alternative designs that balance security, performance, and maintainability.