API style is an operations contract, not a religion
The useful debate is not REST purity versus POST everywhere, but which interface style reduces total product and operations cost.
“Use POST for everything” is not REST best practice, but it can be an organizational choice. The useful question is not whether it is pure. The useful question is whether the interface style reduces total cost across clients, gateways, observability, security, documentation, and operations.
Semantics matter, but so does the system
GET is valuable for safe, cacheable reads. POST is useful for complex bodies, writes, and requests that should not expose parameters in URLs. REST gives semantic clarity and tooling. Unified POST can simplify gateway handling, signing, routing, and multi-client consistency.
When it can be reasonable
- Business actions do not map cleanly to resources.
- Gateways centralize authentication, anti-replay, tracing, and routing.
- Dynamic APIs should not accidentally use HTTP caching.
- Client SDK consistency matters more than URL aesthetics.
The tradeoffs
- You lose natural cache behavior and shareable URLs.
- Action semantics may move into headers or bodies, so documentation must be stronger.
- If POST-everywhere is only laziness, it becomes technical debt.
API style is an operations contract. Pick the contract your team can actually run well.
Operating takeaway
The value is not the feature itself. The value is the repeatable operating model it enables when the team has to deliver real work without losing control.