Die HTTP-QUERY-Methode, spezifiziert in RFC 10008, ist eine sichere, cachebare Request-Methode, die Abfrageparameter im Body statt in der URL überträgt. Sie bietet die Ausdruckskraft eines POST-Payloads, behält aber die Read-only-Semantik von GET bei. Laravel 13.19 ergänzte den HTTP-Client um Http::query() und den Test-Helper queryJson(); Laravel 14 wird einen erstenklassigen Helper Route::query() mitbringen, bis dahin funktioniert Route::match(['QUERY'], ...).

Ausgehend von einer frischen Laravel-13-Anwendung installiert das Tutorial die API-Route-Datei und Scout, setzt in .env den database-Treiber, damit Scout mit WHERE LIKE gegen die bestehende Datenbank sucht. Dann wird ein Article-Modell mit Migration und Factory erstellt, das Trait Searchable eingebunden und toSearchableArray() überschrieben, um nur die Spalten title und body zu indexieren.

Die Route wird in routes/api.php per Route::match(['QUERY'], '/articles/search', ...) registriert. Ein Closure validiert search als Pflicht-String und optional per_page als Integer zwischen 1 und 50. Anschließend wird Article::search($validated['search'])->paginate($validated['per_page'] ?? 15) aufgerufen. Weil QUERY für die Input-Verarbeitung wie POST behandelt wird, lesen $request->input() und die Validierung den JSON-Body direkt. php artisan route:list zeigt QUERY api/articles/search; Clients senden einen JSON-Body wie {"search": "scout", "per_page": 10}.

Tests nutzen den in Laravel 13.19 eingeführten queryJson()-Helper; ein Beispiel verwendet RefreshDatabase, Factories, um Artikel anzulegen, und prüft, dass der Endpunkt den passenden Artikel liefert und den search-Parameter validiert. Auf der Aufruferseite kann der Laravel-HTTP-Client den Endpunkt mit Http::acceptJson()->query('https://example.com/api/articles/search', ['search' => 'scout']) ansprechen.

Ein praktisches Problem: Der eingebaute PHP-Entwicklungsserver lehnt die QUERY-Methode mit 501 Not Implemented ab, bevor Laravel sie sieht, daher taugt php artisan serve nicht. Nginx-basierte Umgebungen wie Laravel Herd und Valet leiten das Verb dagegen durch. Die Laravel-HTTP-Test-Helper umgehen den Server komplett.

Liegt die Route in routes/web.php, verlangt das PreventRequestForgery-Middleware in Laravel 13 ein CSRF-Token, weil es nur HEAD, GET und OPTIONS als Lese-Methoden betrachtet. Bis Laravel 14 QUERY standardmäßig ausnimmt, bietet das Tutorial zwei Lösungen. Erstens: PreventRequestForgery erweitern, isReading() überschreiben, um QUERY aufzunehmen, und das Basis-Middleware im Web-Group über bootstrap/app.php ersetzen. Zweitens: withoutMiddleware(PreventRequestForgery::class) auf einzelne QUERY-Routen anwenden. Der Artikel empfiehlt die Middleware-Überschreibung, weil sie beim Upgrade sauber entfällt. Tests lösen den 419-Fehler nicht aus, solange die Umgebung testing ist – das CSRF-Middleware überspringt dort die Prüfung. QUERY-Handler müssen unabhängig davon schreibfrei bleiben, genau wie GET-Handler.

Vor dem Produktiveinsatz warnt der Artikel: Das Framework ist nur ein Glied der Kette. CDNs, WAFs, Load Balancer oder Proxies können ein unbekanntes Verb blockieren. Browser unterstützen fetch() mit QUERY, HTML-Formulare jedoch nicht; QUERY ist außerdem keine CORS-safelisted-Methode, sodass cross-origin-Anfragen ein Preflight auslösen. Auch wenn QUERY als cachebar definiert ist, implementieren Browser und CDNs das noch nicht. OpenAPI fügte erst in Version 3.2, veröffentlicht im September 2025, eine native Query-Operation hinzu, daher ältere Generatoren/SDKs sie möglicherweise nicht abbilden. Ein internes API, bei dem Client und Server kontrolliert werden, ist der sicherste Ort für erste Experimente.

Mit Laravel 14 lässt sich Route::match(['QUERY'], ...) durch Route::query(...) ersetzen und die CSRF-Middleware-Überschreibung entfernen; der restliche Code bleibt gleich.