Mapping HTTP Methods to Laravel Routes

When you set up Laravel routes for a page or API, the HTTP method tells Laravel which action the client requests. An HTTP method is a request verb, such as GET or POST. A route pairs that method with a URI, the path for the requested address, such as /photos. Laravel checks both to choose which route handles the request.

For a typical resource, use GET to read, POST to create, PUT or PATCH to update, and DELETE to remove. These CRUD (create, read, update, delete) labels are conventions. HTTP gives each method a more precise meaning. Laravel’s router matches the request’s method and URI, and your controller decides what to do with the submitted data.

What each method means

These HTTP meanings come from RFC 9110, with PATCH defined in RFC 5789. Laravel’s resource-controller conventions connect those methods to familiar CRUD actions.

GET reads data or displays a form

A GET request asks the server for a resource’s current representation: data describing it, such as a list of photos or one photo. HTTP defines GET as a safe method: the client is not asking the server to change the resource. The server can still record the request in a log.

Laravel also uses GET routes to display HTML forms. A resource controller’s create action shows a form for a new resource, and edit shows a form for an existing one. These actions display pages; they do not send the data to create or update a resource.

POST commonly creates a resource

A POST request asks the server to process the submitted data according to what the target resource does. Laravel commonly uses POST to create a resource at a collection URI, such as /photos. The server often assigns the new resource an identifier, and Laravel sends the request to store.

POST can serve purposes beyond creation. Its HTTP meaning depends on how the target resource handles the request.

PUT replaces; PATCH applies changes

Both PUT and PATCH reach Laravel’s resource-controller update action, but HTTP gives them different meanings. PUT asks the server to create or replace the target resource using the submitted representation, while PATCH asks it to apply the changes described in the request.

PUT targets a known URI and is idempotent: repeating the same request has the same intended effect as sending it once. PATCH does not have that guarantee by default, though developers can design a particular patch operation to be idempotent. Laravel’s routing convention neither makes PUT replace every field nor defines PATCH’s data format. Your update code and validation decide which fields each request accepts and how those fields change stored data.

DELETE removes a resource from its URI

A DELETE request asks the server to remove the link between the target URI and the resource it identifies. HTTP does not require the server to erase every stored copy of the data. A Laravel controller might delete a database row or mark it as soft-deleted; its implementation can also take another form. The DELETE method alone does not specify what.

DELETE is idempotent: repeating the request should leave the intended result unchanged, though the server’s response can differ.

How Laravel matches methods to routes

Each Laravel route registration names the HTTP method and URI that the route accepts. These routes use the /photos collection path for reading and creating. The routes for individual photos include a {photo} parameter:

Route::get('/photos', [PhotoController::class, 'index']);
Route::post('/photos', [PhotoController::class, 'store']);
Route::put('/photos/{photo}', [PhotoController::class, 'update']);
Route::patch('/photos/{photo}', [PhotoController::class, 'update']);
Route::delete('/photos/{photo}', [PhotoController::class, 'destroy']);

Laravel provides method-specific registration helpers, including Route::get, Route::post, Route::put, Route::patch, and Route::delete. The router checks both the request’s method and its URI. That lets a GET /photos request and a POST /photos request reach different handlers. The Laravel routing documentation also explains how to register one route for several specified methods with Route::match.

For conventional resource routes, Route::resource('photos', PhotoController::class) registers the standard controller actions. Laravel sends POST requests to the collection URI to store. For an item URI, PUT and PATCH requests go to update, while DELETE requests go to destroy. The resource registrar sets these method-to-action mappings.

A full web resource also includes GET routes for create and edit, which display HTML forms. An API resource leaves out those two routes. In both cases, Laravel’s route mapping selects a controller action. The controller code handles validation and authorization. It also saves data.

Sending PUT, PATCH, and DELETE from HTML forms

HTML forms submit GET or POST requests directly. For a Laravel route that uses PUT, PATCH, or DELETE, submit the form as POST and include a hidden _method field set to the intended method. Blade’s @method directive creates that field:

id }}">
    @csrf
    @method('PATCH')
    <!-- Form fields -->

Laravel reads the field and treats the request as PATCH when choosing a route. Method spoofing lets an HTML form reach the intended route. It does not change what PATCH means under HTTP.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com