How Many HTTP Methods Does a RESTful API Actually Use?

A RESTful API conventionally uses five HTTP methods, each mapped to a specific meaning — sticking to these conventions consistently is what makes an API predictable to any developer already familiar with REST, without needing to read documentation for every single endpoint.

GET — retrieve a resource

GET /products        // list all products
GET /products/42      // retrieve a single product

GET requests should never modify server state — they're expected to be safe to call repeatedly (idempotent) and safe to cache.

POST — create a new resource

POST /products
Content-Type: application/json

{"name": "Widget", "price": 19.99}

POST is the one common method that's genuinely not idempotent by convention — calling it twice with the same payload conventionally creates two separate resources, not one.

PUT — replace a resource entirely

PUT /products/42
Content-Type: application/json

{"name": "Widget", "price": 24.99, "description": "Updated widget"}

PUT conventionally replaces the entire resource — any field not included in the request body is conventionally expected to be cleared or reset, not left untouched. This is the detail most often misused in practice.

PATCH — partially update a resource

PATCH /products/42
Content-Type: application/json

{"price": 24.99}

PATCH updates only the fields actually included in the request, leaving everything else on the resource unchanged — this is the more commonly appropriate choice for a typical "edit one field" form submission, where PUT's full-replacement semantics would be a mismatch for the actual intent.

DELETE — remove a resource

DELETE /products/42

Laravel's Route::resource and these five methods

Route::resource('products', ProductController::class);

This single line maps index/show to GET, store to POST, update to PUT/PATCH (Laravel accepts both), and destroy to DELETE — directly following the conventional REST method mapping described above.

HEAD and OPTIONS: less commonly discussed, but part of HTTP too

HEAD returns the same headers a GET would, without a response body — useful for checking if a resource exists or has changed without downloading it. OPTIONS returns which methods a given endpoint supports, and is what browsers send automatically as a CORS "preflight" request before certain cross-origin calls.

Why sticking to convention matters more than the exact count

The real value of REST's method conventions isn't the specific number five — it's that a developer who already understands REST can correctly guess what DELETE /products/42 or PATCH /products/42 does without reading a single line of documentation, as long as the API actually follows the convention consistently rather than, say, using POST for updates and deletes as well.