Statuscode 405 Method Not Allowed: Der Fehler "Falsches Werkzeug"

Sie versuchen, ein Bild an Ihre Wand zu hängen. Sie haben einen Schraubenzieher, aber was Sie wirklich brauchen, ist ein Hammer. Egal wie sehr Sie sich anstrengen, dieser Schraubenzieher wird den Nagel einfach nicht in die Wand treiben. Das Werkzeug, das Sie verwenden, passt nicht zu der Aufgabe, die Sie erledigen möchten.

Dies ist genau die Situation, die einer der spezifischsten und hilfreichsten Fehlercodes von HTTP beschreibt: 405 Method Not Allowed.

Im Gegensatz zum allgemeineren 404 Not Found (der besagt: „Ich kann nicht finden, wonach Sie suchen“) oder 400 Bad Request (der besagt: „Ich verstehe nicht, was Sie sagen“), ist der 405-Fehler unglaublich präzise. Er besagt: „Ich habe die gesuchte Ressource gefunden, aber Sie verwenden die falsche HTTP-Methode, um damit zu interagieren.“

Es ist die Art des Servers, Ihnen zu sagen: „Ich weiß, was /api/users ist, aber Sie können es nicht DELETE-en. Versuchen Sie stattdessen GET zu verwenden.“

Wenn Sie als Entwickler mit RESTful APIs arbeiten, ist das Verständnis des 405-Statuscodes entscheidend für die korrekte Erstellung und Nutzung von APIs.

In diesem detaillierten Blogbeitrag werden wir alles untersuchen, was Sie über den Status 405 Method Not Allowed wissen müssen: was er bedeutet, warum er auftritt, häufige Szenarien, wie man ihn behebt und Best Practices für den eleganten Umgang damit.

💡

Wenn Sie diesen Fehler effizient testen und debuggen möchten, laden Sie Apidog kostenlos herunter. Apidog ist ein All-in-One-Tool für API-Tests und -Dokumentation, das die Interaktion mit APIs, das Erkennen und Beheben von Fehlern wie 405 und die Optimierung Ihres Entwicklungs-Workflows erleichtert.

Download

Nun wollen wir den Zweck, die Funktionsweise und die praktischen Auswirkungen des HTTP-Statuscodes 405 Method Not Allowed untersuchen.

Das Problem: HTTP-Methoden und RESTful Design

Um 405 zu verstehen, müssen wir kurz darauf zurückkommen, wie RESTful APIs funktionieren. Im RESTful Design kann dieselbe URL je nach verwendeter HTTP-Methode (Verb) unterschiedlich reagieren:

GET /api/users - Eine Liste von Benutzern abrufen
POST /api/users - Einen neuen Benutzer erstellen
PUT /api/users/123 - Benutzer 123 aktualisieren (vollständiger Ersatz)
PATCH /api/users/123 - Benutzer 123 teilweise aktualisieren
DELETE /api/users/123 - Benutzer 123 löschen

Der 405-Fehler tritt auf, wenn Sie versuchen, eine Methode zu verwenden, die der Server für diesen spezifischen Endpunkt nicht implementiert hat. Zum Beispiel würde der Versuch, POST an /api/users/123 zu senden (was typischerweise nur GET, PUT, PATCH, DELETE unterstützt), wahrscheinlich einen 405 zurückgeben.

Was bedeutet HTTP 405 Method Not Allowed eigentlich?

Der Statuscode 405 Method Not Allowed zeigt an, dass der Server die Zielressource (die von Ihnen angeforderte URL) kennt, aber die in der Anfrage verwendete HTTP-Methode nicht unterstützt.

Für eine korrekte 405-Antwort gibt es eine entscheidende Anforderung: Sie muss einen Allow-Header enthalten, der die HTTP-Methoden auflistet, die für die angeforderte Ressource unterstützt werden.

Eine korrekte 405-Antwort sieht so aus:

HTTP/1.1 405 Method Not AllowedAllow: GET, HEAD, OPTIONSContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "POST method is not supported for this endpoint."
}

Lassen Sie uns die Schlüsselkomponente aufschlüsseln:

Allow: GET, HEAD, OPTIONS: Dies ist der wichtigste Teil. Dieser Header teilt dem Client genau mit, welche Methoden erlaubt sind. Es ist, als würde der Server sagen: „Sie können hier keinen Hammer verwenden, aber Sie können stattdessen diese drei Werkzeuge benutzen.“

Einfach ausgedrückt hat der Client eine gültige HTTP-Methode wie GET, POST, PUT, DELETE usw. gesendet, aber der Server erlaubt diese bestimmte Methode auf der angeforderten URL oder dem Endpunkt nicht.

Warum tritt ein 405-Fehler auf?

Ein 405 tritt auf, wenn die in der HTTP-Anfrage verwendete Methode für die Ressource nicht zulässig ist. Häufige Gründe sind:

GET auf einem Endpunkt aufrufen, der nur POST unterstützt.
PUT verwenden, wo nur DELETE unterstützt wird.
OPTIONS-Anfragen an Ressourcen senden, die dies nicht zulassen.
Fehlkonfigurierte Server-Routing- oder HTTP-Methoden-Handler.
Falsche REST-API-Nutzung oder veraltete Dokumentation.

Das Verständnis der Grundursache hilft, das Problem effizient zu beheben.

Warum Server 405 statt 404 zurückgeben

Sie fragen sich vielleicht, warum nicht einfach ein 404 Not Found zurückgegeben wird?

Nun, ein 404 bedeutet, dass die Ressource überhaupt nicht gefunden wurde, aber ein 405 bedeutet, dass die Ressource existiert, nur nicht mit dieser Methode.

Diese Unterscheidung ist für Entwickler wichtig, weil sie Ihnen sagt:

Sie sind am richtigen Ort.
Sie verwenden nur das falsche Werkzeug.

Wie es funktioniert: Ein konkretes Beispiel

Stellen wir uns einen schreibgeschützten API-Endpunkt vor, der Produktinformationen bereitstellt.

Die gültige Anfrage:

GET /api/products/123 HTTP/1.1Host: api.example.com

Server-Antwort: 200 OK mit Produktdaten.

Die ungültige Anfrage:

Ein Client versucht fälschlicherweise, das Produkt mit PUT zu aktualisieren:

PUT /api/products/123 HTTP/1.1Host: api.example.comContent-Type: application/json
{"name": "New Product Name"}

Die 405-Antwort des Servers:

HTTP/1.1 405 Method Not AllowedAllow: GET, HEADContent-Type: application/json
{
  "error": "Method Not Allowed",
  "message": "The PUT method is not supported for this resource."
}

Der Header Allow: GET, HEAD teilt dem Client klar mit, dass dies ein schreibgeschützter Endpunkt ist. Der Client weiß nun genau, was schiefgelaufen ist und wie er es beheben kann.

Warum der Allow-Header so wichtig ist

Der Allow-Header verwandelt den 405 von einem frustrierenden Fehler in eine hilfreiche Konversation. Ohne ihn würde ein Client raten müssen:

Mit Allow-Header: „Ich kann hier nicht PUT-en, aber ich kann GET oder HEAD verwenden.“
Ohne Allow-Header: „Ich kann hier nicht PUT-en. ¯_(ツ)_/¯ Viel Glück beim Herausfinden, was Sie tun können!“

Deshalb schreibt die HTTP-Spezifikation vor, dass Server den Allow-Header in 405-Antworten aufnehmen müssen. Das macht den Code wirklich nützlich, anstatt nur frustrierend.

Wie sieht eine 405-Antwort aus?

Server antworten mit dem Status 405 zusammen mit einem Allow-Header, der die zulässigen HTTP-Methoden angibt. RFC 7231 (HTTP/1.1-Spezifikation) schreibt vor, dass, wenn ein 405-Statuscode gesendet wird, der Server einen Allow-Header enthalten MUSS, der die zulässigen HTTP-Methoden für diese Ressource auflistet.

Beispielantwort:

textHTTP/1.1 405 Method Not Allowed Allow: GET, HEAD, OPTIONS Content-Type: text/html
<html> <body> <h1>405 Method Not Allowed</h1> <p>The requested method POST is not supported for this resource.</p> </body> </html>

Der Allow-Header ist entscheidend, da er den Client darüber informiert, welche Methoden akzeptabel sind, und so Korrekturen ermöglicht.

Auf diese Weise wissen Clients, welche Methoden unterstützt werden, und können ihre Anfragen entsprechend anpassen.

Häufige Szenarien, die 405-Fehler auslösen

1. Schreibgeschützte Endpunkte

Wie in unserem obigen Beispiel sind einige Ressourcen absichtlich schreibgeschützt. Sie können sie mit GET abrufen, aber nicht mit PUT, PATCH oder DELETE ändern.

2. Falsche Methode für die Aktion

Dies ist wahrscheinlich die häufigste Ursache. Entwickler verwechseln, welche Methode für welche Aktion verwendet werden soll.

Verwendung von GET zum Erstellen einer Ressource (sollte POST sein)
Verwendung von POST zum Aktualisieren einer Ressource (sollte PUT oder PATCH sein)
Verwendung von DELETE auf einer Sammlungs-URL wie /api/users (sollte auf einer spezifischen Ressource wie /api/users/123 sein)

3. Fehlende Methodenimplementierung

Der API-Designer hat möglicherweise einfach eine bestimmte Methode für einen Endpunkt nicht implementiert. Zum Beispiel könnte ein Endpunkt GET und POST unterstützen, aber nicht PUT oder DELETE.

4. Web Application Firewalls (WAFs) und Sicherheitsregeln

Manchmal blockieren Sicherheitskonfigurationen absichtlich bestimmte Methoden. Zum Beispiel könnte eine WAF aus Sicherheitsgründen PUT-, PATCH- und DELETE-Methoden auf bestimmten Pfaden blockieren und einen 405 zurückgeben.

405 vs. andere 4xx-Fehler: Den Unterschied kennen

Es ist wichtig, 405 von anderen Client-Fehlercodes zu unterscheiden.

405 Method Not Allowed vs. 404 Not Found:

405 bedeutet „Diese URL existiert, aber nicht für diese Methode.“

404 bedeutet „Diese URL existiert für keine Methode.“

405 Method Not Allowed vs. 501 Not Implemented:

405 bedeutet „Ich weiß, was Sie tun möchten, aber ich lasse Sie es für diese spezifische Ressource nicht tun.“ (Client-Fehler)

501 bedeutet „Ich weiß überhaupt nicht, wie ich diese HTTP-Methode für irgendeine Ressource handhaben soll.“ (Server-Fehler)

405 Method Not Allowed vs. 403 Forbidden:

405 bedeutet „Diese Operation ist für niemanden verfügbar.“ (Methodenbeschränkung)

403 bedeutet „Diese Operation ist verfügbar, aber nicht für Sie mit Ihren aktuellen Berechtigungen.“ (Autorisierungsbeschränkung)

Häufige Szenarien, in denen 405 auftritt

RESTful APIs: Versuch, PUT an einen Endpunkt zu senden, der nur GET oder POST unterstützt.
Webformulare: Absenden eines Formulars mit einer GET-Methode an einen Endpunkt, der POST erwartet.
Falsch konfigurierte Routen: Server-Routen, die bestimmte Methoden nicht korrekt verarbeiten.
Middleware-Probleme: Sicherheitssoftware, die bestimmte Methoden blockiert oder filtert.
Statische Ressourcen: Anfordern von POST auf einer statischen Bild- oder Datei-URL.

Wie Clients 405 Method Not Allowed handhaben sollten

Wenn Clients eine 405-Antwort erhalten, sollten sie:

Überprüfen Sie den Allow-Header, um unterstützte HTTP-Methoden zu identifizieren.
Ändern Sie die Anfrage, um eine erlaubte Methode zu verwenden.
Wiederholen Sie die Anfrage entsprechend.
Behandeln Sie Fehler in Benutzeroberflächen oder Workflows elegant.
Informieren Sie Benutzer klar über nicht unterstützte Aktionen.

Wie Entwickler 405-Fehler beheben können

Überprüfen Sie Server-Routing und -Konfiguration: Stellen Sie sicher, dass Routen alle erwarteten HTTP-Methoden verarbeiten.
API-Dokumentation überprüfen: Überprüfen Sie die korrekte Verwendung der HTTP-Methode.
Methoden-Handler implementieren: Definieren Sie Handler für alle erlaubten Methoden explizit.
Mit korrekten Allow-Headern antworten: Verbessern Sie die Benutzerfreundlichkeit des Clients.
Client-Anfragen validieren: Falsche Methodennutzung frühzeitig in Ihren Client-Anwendungen abfangen.
405-Fehler protokollieren: Um wiederkehrende Probleme zu überwachen und zu beheben.

Beispiele für HTTP-Methoden und zulässige Verwendung

HTTP-Methode	Typischer Anwendungsfall
GET	Ressource oder Daten abrufen
POST	Ressource erstellen oder Aktionen ausführen
PUT	Ressource aktualisieren oder ersetzen
DELETE	Ressource entfernen
PATCH	Ressource teilweise aktualisieren
OPTIONS	Informationen zu unterstützten Methoden anfragen

Eine Diskrepanz zwischen Methode und Ressourcenfähigkeiten löst 405 aus.

Testen von 405-Antworten mit Apidog

Das Testen, ob Ihre API für nicht unterstützte Methoden korrekt 405 zurückgibt, ist ein Merkmal robuster API-Entwicklung. Apidog macht diesen Prozess unglaublich einfach.

Mit Apidog können Sie:

Alle Methoden einfach testen: Nehmen Sie eine beliebige Endpunkt-URL und wechseln Sie mit einem einzigen Klick schnell zwischen GET-, POST-, PUT-, PATCH-, DELETE-Methoden, um zu sehen, welche unterstützt werden.
Den Allow-Header validieren: Wenn Sie eine 405-Antwort erhalten, zeigt Apidog Ihnen den Allow-Header in den Antwortdetails deutlich an. Sie können überprüfen, ob er die korrekte Liste der Methoden enthält.
Methodentests automatisieren: Erstellen Sie Test-Suites, die automatisch überprüfen, ob nicht unterstützte Methoden 405 mit dem korrekten Allow-Header zurückgeben, während unterstützte Methoden den erwarteten 2xx-Status zurückgeben.
Client-seitigen Code debuggen: Wenn Sie eine Client-Anwendung erstellen, die einen 405 empfängt, können Sie Apidog verwenden, um die genaue Anfrage und Antwort zu replizieren, was Ihnen hilft, das Problem in Ihrem Client-Code zu verstehen und zu beheben.
API-Verhalten dokumentieren: Verwenden Sie Apidog, um zu dokumentieren, welche Methoden für jeden Endpunkt unterstützt werden, wodurch diese Informationen für andere Entwickler, die Ihre API nutzen, klar werden.

Download

Anstatt zu raten, erhalten Sie in Sekundenschnelle Klarheit. Laden Sie Apidog kostenlos herunter und machen Sie die Fehlerbehebung bei HTTP-Fehlern mühelos.

Best Practices für den Umgang mit 405ern

Für API-Entwickler (Serverseite):

Fügen Sie immer den Allow-Header in 405-Antworten ein. Dies ist für einen konformen HTTP-Server nicht optional.
Seien Sie konsistent bei der Methodennutzung in Ihrer API. Wenn die meisten Sammlungs-Endpunkte GET und POST unterstützen, sollten Sie keinen haben, der ohne triftigen Grund nur GET unterstützt.
Geben Sie eine hilfreiche Fehlermeldung im Antworttext an, insbesondere für APIs, die von anderen Entwicklern genutzt werden.
Erwägen Sie die Verwendung von OPTIONS: Implementieren Sie die OPTIONS-Methode für Ihre Endpunkte, die denselben Allow-Header zurückgeben sollte. Dies gibt Clients eine Möglichkeit, unterstützte Methoden zu entdecken, ohne Fehler auszulösen.

Für API-Konsumenten (Client-Seite):

Überprüfen Sie den Allow-Header, wenn Sie einen 405 erhalten. Er sagt Ihnen genau, was Sie stattdessen tun können.
Verwenden Sie die OPTIONS-Methode, um unterstützte Methoden zu entdecken, bevor Sie andere Operationen versuchen.
Behandeln Sie 405-Fehler elegant in Ihrem Code – behandeln Sie sie nicht als fatale Fehler, sondern als Anleitung zur Korrektur Ihrer Anfrage.

Die Rolle der OPTIONS-Methode

Die OPTIONS-Methode ist der proaktive Verwandte der 405-Antwort. Anstatt eine Operation zu versuchen und abgelehnt zu werden, kann ein Client den Server zuerst fragen, welche Methoden unterstützt werden:

Anfrage:

OPTIONS /api/products/123 HTTP/1.1Host: api.example.com

Antwort:

HTTP/1.1 200 OKAllow: GET, HEAD, OPTIONS

Dies ist eine wesentlich elegantere Methode, die Fähigkeiten einer API zu entdecken, ohne Fehler auszulösen.

Fehlerbehebung bei häufigen 405-Problemen

Überprüfen Sie Routendefinitionen und HTTP-Verb-Handler.
Überprüfen Sie Proxy- oder Firewall-Konfigurationen, die bestimmte Methoden blockieren könnten.
Suchen Sie nach Rechtschreibfehlern oder Diskrepanzen in Client-Anfragen.
Verwenden Sie Debugging-Tools wie Apidog, um vollständige Anfrage-/Antwortzyklen zu erfassen.
Testen Sie über verschiedene Umgebungen hinweg, um produktionsspezifische Probleme zu erkennen.

Sicherheitsauswirkungen von 405

405 kann auch Sicherheitsauswirkungen haben:

Das Deaktivieren unsicherer Methoden (wie TRACE) hilft, Angriffe zu verhindern.
Zu viele Informationen im Allow-Header könnten Angreifern Hinweise geben.
Konsistente 405-Behandlung vermeidet das Preisgeben von Serverdetails.

Fazit: Von Frustration zu Klarheit

Der 405 Method Not Allowed Statuscode ist nicht nur eine zufällige Hürde. Er ist ein wertvolles Signal dafür, dass die Ressource existiert, aber die von Ihnen verwendete Methode nicht akzeptiert. Der HTTP-Statuscode 405 Method Not Allowed ist ein perfektes Beispiel dafür, wie gutes API-Design klares, umsetzbares Feedback liefert. Er verwandelt eine potenziell verwirrende Sackgasse in ein hilfreiches Wegweiser, der besagt: „Diesen Weg können Sie nicht gehen, aber hier sind die Wege, die Ihnen offenstehen.“

Für API-Entwickler ist die Implementierung korrekter 405-Antworten mit präzisen Allow-Headern ein Zeichen von Professionalität und Liebe zum Detail. Für API-Konsumenten ist das Verständnis, wie man 405-Fehler liest und darauf reagiert, entscheidend für den Aufbau robuster, selbstkorrigierender Anwendungen.

Wenn Sie also das nächste Mal auf einen 405-Fehler stoßen, lassen Sie sich nicht frustrieren – lesen Sie den Allow-Header. Der Server versucht Ihnen zu helfen, erfolgreich zu sein. Und wenn Sie selbst APIs erstellen oder testen, gibt Ihnen ein Tool wie Apidog die Möglichkeit, sicherzustellen, dass Ihre Methodennutzung korrekt ist und Ihre Fehlerbehandlung so hilfreich ist, wie sie sein sollte.

Download