Reference

HTTP Methods

Start here when you know what your endpoint should do, but you are not sure which verb makes the contract honest.

Try Requests Search by Concept

Tip: press / to focus search.

Method

HTTP DELETE Method: Remove Resources

Learn how the HTTP DELETE method works, when to use it, and best practices for deleting resources in REST APIs.

Method

HTTP GET Method: Complete Guide with Examples

Learn how the HTTP GET method works. Understand when to use GET requests, query parameters, caching, and best practices with real-world examples.

Method

HTTP HEAD Method

Learn how HTTP HEAD requests retrieve resource metadata (headers) without downloading the body. Useful for checking existence, size, and modification dates.

Method

HTTP OPTIONS Method

Learn how HTTP OPTIONS requests discover server capabilities, supported methods, and handle CORS preflight checks for cross-origin requests.

Method

HTTP PATCH Method

Learn how HTTP PATCH requests apply partial modifications to resources. Understand JSON Patch, merge patch formats, and when to use PATCH vs PUT.

Method

HTTP POST Method: Complete Guide with Examples

Learn how the HTTP POST method works. Understand when to use POST requests, request bodies, form submissions, and API calls with practical examples.

Method

HTTP PUT Method: Update Resources

Learn how the HTTP PUT method works, when to use PUT vs POST vs PATCH, and best practices for updating resources in REST APIs.

Pick The Verb Before You Pick The Route

Most method mistakes come from treating every write as POST. The better question is: what promise does this endpoint make to the caller? Method choice affects retries, caching, browser behavior, and how other developers read your API.

Safe methods: GET, HEAD, and OPTIONS are for reads, previews, and capability checks. If one of them changes data, your API will surprise clients and caches.
Idempotent methods: PUT and DELETE are easier to retry because repeating the same request should leave the resource in the same end state.
Cache-aware methods: GET plays well with browser history, links, and caches. POST usually does not unless you add explicit rules.
Write methods: POST, PUT, PATCH, and DELETE all change state, but they signal different intent: create, replace, partially update, or remove.

Use This Hub When You Are Stuck On

This page is most useful when the route is easy to name but the semantics are still fuzzy.

Whether a handler should create something new, replace a known resource, or patch part of it.
Whether a client or job runner can safely retry after a timeout.
Why a browser form, CDN, or API client is behaving differently because the verb changed.

Questions API Teams Ask

When should I use PUT instead of PATCH?

Use PUT when the client can send the full intended representation of the resource. Use PATCH when it only knows the fields that changed and should not have to resend everything else.

Is POST always the right choice for writes?

No. POST is the most flexible verb, but that flexibility is also why it is overused. If the operation is clearly a replace, partial update, or delete, PUT, PATCH, or DELETE usually communicates the contract better.

Does DELETE always mean hard-delete the record?

No. DELETE means the target resource should no longer be available in that form. Internally you can soft-delete, archive, tombstone, or queue cleanup work as long as the external contract is clear.