Which HTTP method fits which job
Method choice is the first thing that stalls an API design. Pick what the request should do and whether it must survive an automatic retry, and you get the method for that job together with its safe, idempotent and cacheable flags and whether a request body is used. The table above lines up all nine standard methods against the same columns.
Safe means the request only reads and does not change server state. Idempotent means sending the same request several times leaves the server in the same state as sending it once. Those two properties and cacheability are set by RFC 9110, which defines GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS and TRACE, and by RFC 5789, which defines PATCH. The values shown reflect those specs as of October 2026 and are not ratings invented here.
This page reports what the specs say; it does not check whether your framework, server or proxy actually allows a method. Gateways and firewalls often block PATCH or TRACE, so verify in your own environment. Status code selection, header design and authentication are out of scope.
Frequently Asked Questions
Use POST when the server decides the URI of the new resource, and PUT when the client picks the URI and replaces its whole contents. PUT is idempotent and safe to retry; POST is not.
A patch document can carry state-dependent instructions such as "add one to this value". The spec therefore does not guarantee idempotency, so guard retries with a conditional request.
The spec gives a GET body no defined meaning and intermediaries may drop or reject it. For long conditions a query string or a POST is the safer choice.