Design every route for browsing, creating, updating, and deleting books, then verify their HTTP contracts.
Target map
Seven routes, one coherent resource.
/booksindex200/books/createcreate200/booksstore201 / 302/books/{id}show200 / 404/books/{id}/editedit200 / 404/books/{id}update200 / 302/books/{id}destroy204 / 302A route is a contract
A route means more than an URL opening a page. It defines a client contract: method, path, parameters, protection, and action.
GET /books promises to read the collection. POST /books promises creation. They share a path but expose different intentions and responses.
The HTTP interface should be understandable without reading controller code. SQL, HTML, and long conditions do not belong in routes.
Always say method and path: GET /books, not only /books.
Route::get('/books', [BookController::class, 'index']);Choose the HTTP method
The method announces the effect. GET reads, POST creates or triggers, PATCH partially changes, and DELETE removes.
GET must avoid intentional business side effects: refreshing must never create another book.
POST is not a stronger GET. PATCH /books/42 targets an existing resource; DELETE expresses removal.
A normal link should generally be GET and never delete data.
Design URLs
An URL describes a resource, not PHP implementation. Prefer /books/42 over /showBook.php?id=42.
Use consistent plural collection names. An identifier selects one member; subpaths represent pages or relationships.
A good URL survives controller, database, and view replacements.
Avoid technical verbs when the HTTP method already expresses the action.
Dynamic parameters and constraints
In /books/{id}, id comes from the path. You must still define acceptable values.
A numeric constraint keeps /books/hello away from an integer controller. It does not replace business validation: 42 may be valid but absent.
Distinguish no route, invalid parameter, and missing resource.
Validate shape early, then existence and rules in the appropriate layer.
Route::get('/books/{id}', [BookController::class, 'show'])
->whereNumber('id');Named routes and URLs
A named route provides a stable identifier such as books.show so views do not copy /books/{id}.
When the path changes, name-based calls survive one declaration update.
Use a regular resource.action convention independent of visible labels.
A name centralizes a contract otherwise copied into many views.
$url = route('books.show', ['id' => $book->id]);Groups, prefixes, and middleware
A group applies a common /admin prefix, auth middleware, or namespace.
Grouping avoids repeated protection and makes policy visible.
Middleware order matters. Security headers must also cover early 401, 403, and 429 responses.
Declare shared protection at the nearest shared level without hiding it.
Route::prefix('/admin')
->middleware(['auth', 'role:editor'])
->group(function (): void {
Route::patch('/books/{id}', [BookController::class, 'update']);
Route::delete('/books/{id}', [BookController::class, 'destroy']);
});Separate web and API
Web and API can share models while exposing different response contracts.
Web commonly uses sessions, CSRF, redirects, and HTML. APIs use JSON, tokens, explicit statuses, and /api/v1.
Share business rules through models or services while each surface adapts Request and Response.
Shared business logic does not mean mixed HTTP contracts.
routes/webapp.phproutes/api.phpOrganize files
A small project fits routes/webapp.php. Hundreds of entries become an unreadable map.
Group by surface or feature: webapp.php, api.php, admin.php, then MovieRoute for route-per-controller APIs.
Keep loading discoverable and avoid unexplained filesystem magic.
Add a file to clarify a real boundary, not to populate empty folders.
Distinguish 404 and 405
404 means no matching route or resource. 405 means the path exists but not for the received method.
GET /books/42 can be 404 when absent. POST /books/42 is 405 when only GET, PATCH, and DELETE exist.
A 405 may announce accepted methods with Allow.
Diagnose method-path before resource existence.
Test the map
A route is complete only when success, wrong methods, invalid parameters, missing resources, and middleware are verified.
Observe statuses, headers, redirects, and essential content without irrelevant visual coupling.
Verify sensitive routes remain inaccessible without authentication.
Every important contract branch deserves a reproducible test.
Assembly
The complete CRUD map.
Read it as an HTTP table of contents. Every declaration should lead to a short, focused controller method.
Route::get('/books', [BookController::class, 'index'])->name('books.index');
Route::get('/books/create', [BookController::class, 'create'])->name('books.create');
Route::post('/books', [BookController::class, 'store'])->name('books.store');
Route::get('/books/{id}', [BookController::class, 'show'])->name('books.show');
Route::get('/books/{id}/edit', [BookController::class, 'edit'])->name('books.edit');
Route::patch('/books/{id}', [BookController::class, 'update'])->name('books.update');
Route::delete('/books/{id}', [BookController::class, 'destroy'])->name('books.destroy');Final project
Build and test BookRoute.
- Write seven CRUD routes without business logic.
- Name them using books.action.
- Constrain id to a positive integer.
- Protect creation, update, and deletion.
- Add the /api/v1/books JSON version.
- Test success, 404, 405, validation, and denied access.
Reasoned solution
Verify contracts, not only syntax.
Quality depends on boundaries: no database query in routes, no secrets, coherent methods, stable names, explicit constraints, and visible protection.
Why /books/create when POST /books creates?
GET /books/create displays the form without changing data. POST /books then processes its submission.
Should there be one route class per controller?
For a medium API, MovieRoute with MovieController is clear. For a small site, webapp.php is enough. Optimize discovery without empty folders.