vege - Fotolia
Die 5 wichtigsten HTTP-Methoden in der RESTful-API-Entwicklung
HTTP-Methoden sind zwar nicht generell komplex. Entwickler müssen aber dennoch die wichtigsten HTTP-Methoden für die RESTful-API-Entwicklung kennen und verstehen.
REST ist wichtig, um sicherzustellen, dass unabhängig voneinander entwickelte Clients und Server sicher interagieren können.
HTTP-basierte APIs lassen sich leicht in RESTful-Webdienste integrieren, wirken jedoch oft unlogisch, überlappend und ineffizient. Es gibt viele Möglichkeiten, HTTP-Methoden zu verwenden, von denen viele nicht mit den RESTful-Prinzipien kompatibel sind. Daher ist es wichtig, die HTTP-API-Methoden zu überprüfen und zu verstehen, wie man sie richtig einsetzt.
Werfen wir einen kurzen Blick auf den Hauptunterschied zwischen Ressourcen und Ressourcensammlungen und untersuchen dann die fünf grundlegenden HTTP-Methoden, die alle, die mit der Entwicklung von RESTful APIs zu tun haben, kennen sollten, sowie vier zusätzliche Methoden, die in spezialisierteren Anwendungen nützlich sein können.
HTTP-Ressourcen versus Ressourcensammlungen
Eine HTTP-Ressource ist vergleichbar mit einer Datendatei: Entwickler können den Inhalt der Ressource lesen und aktualisieren, und sie wird auf einem Server gehostet und ist über eine URL ansprechbar. Eine Ressourcensammlung ist eine Gruppe verwandter Ressourcen, die einer Gruppe verwandter Dateien ähnelt.
Die Beziehung zwischen den Ressourcen innerhalb einer Sammlung hängt von der Software ab, die die Sammlung unterstützt – insbesondere von der Implementierung dieser Software. Wenn die Implementierungen dem Verhalten der Clients keine bestimmte Reihenfolge zuweisen, kann dies zu Inkonsistenzen führen und dazu, dass Anwendungen nicht mehr funktionieren.
Methode 1: POST
POST ist die einzige HTTP-Methode für die RESTful-API-Entwicklung, die hauptsächlich mit Ressourcensammlungen arbeitet. Wenn eine untergeordnete Ressource in einer Sammlung erstellt wird, wird durch die Anwendung von POST auf die übergeordnete Ressource diese aufgefordert, eine neue Ressource zu erstellen, sie mit der richtigen Hierarchie zu verknüpfen und eine dedizierte URL zur späteren Bezugnahme zurückzugeben. Beachten Sie jedoch, dass POST nicht idempotent ist; die mehrfache Verwendung dieser Methode führt zu inkonsistenten Ergebnissen.
Ein wesentlicher Vorteil von POST besteht darin, dass Entwickler Ressourcen explizit definieren können. Diese Funktion hilft zu verhindern, dass Teams versehentlich untergeordnete Ressourcen erstellen, die den Code verunreinigen, Referenzen durcheinanderbringen und zu Problemen in Anwendungen führen.
Idempotente versus nicht-idempotente Methoden
Ein HTTP-API-Design sollte niemals zu einer Client-Anfrage führen, die den Server in einen unsicheren oder instabilen Zustand versetzt, sei es aufgrund einer Fehlerbehebung oder eines Softwarefehlers.
Eine Methode gilt als sicher, wenn sie den Zustand eines Servers nicht beeinflusst; alle derartigen Methoden sind auch idempotent. Eine Methode ist idempotent, wenn der Client die Anfrage wiederholen kann, wahrscheinlich durch Softwarefehler- oder Netzwerkfehlerbehebung, ohne dass der Server in einen fehlerhaften Zustand gerät. Von den fünf häufigsten HTTP-Methoden für die Entwicklung von RESTful APIs ist POST nicht idempotent und PATCH kann idempotent sein oder auch nicht, je nachdem, ob seine Verwendung an Bedingungen geknüpft ist. Um eine API fehlertolerant zu machen, empfiehlt es sich, nach Möglichkeit idempotente Methoden zu verwenden und die Verwendung nicht-idempotenter Methoden zu dokumentieren.
Methode 2: PUT
Das Äquivalent von POST für eine einzelne Ressource ist PUT, das eine Ressource aktualisiert, indem es ihren Inhalt vollständig ersetzt. Als RESTful API HTTP-Methode ist PUT die gängigste Methode zur Aktualisierung von Ressourceninformationen.
Es ist möglich, eine Ressource mit einer PUT-Methode zu erstellen, aber dieser Ansatz birgt das Risiko, dass versehentlich Ressourcen erstellt werden. Die Anwendung von PUT auf eine Sammlung von Ressourcen ersetzt die gesamte Ressourcensammlung, was normalerweise nicht beabsichtigt ist.
Methode 3: PATCH
PATCH ist eine weitere HTTP-Methode zum Aktualisieren von Ressourcen. Anstatt Ressourcen zu ersetzen, wie es bei der PUT-Methode der Fall ist, werden bei PATCH die Ressourceninhalte geändert. Diese Änderungen sollten im Allgemeinen in einem Standardformat wie JSON oder XML ausgedrückt werden.
Ähnlich wie bei PUT ist es keine gute Idee, PATCH-Methoden gezielt auf eine ganze Ressourcensammlung anzuwenden, es sei denn, es besteht die Absicht, jede darin enthaltene Ressource zu aktualisieren.
Methode 4: GET
Die am häufigsten verwendete HTTP-Methode ist GET, die eine darstellende Ansicht der Inhalte und Daten einer Ressource zurückgibt. Die Verwendung von GET im schreibgeschützten Modus ist wichtig, um die Sicherheit der Daten zu gewährleisten und die Ressource idempotent zu halten. GET sollte unabhängig davon, wie oft der Client diese Methode verwendet, dieselben Ergebnisse zurückgeben, es sei denn, ein anderer Client ändert sie in der Zwischenzeit.
Ein Client kann die GET-Methode manchmal verwenden, um den Inhalt einer Ressource zu ändern, doch dies ist unsicher. Es kommt häufig vor, dass die Fähigkeit eines Clients, eine Ressource zu patchen, beeinträchtigt wird, wenn die Ressource eine Änderung erkennt, seit der PATCH-Client zuletzt ein GET ausgeführt hat.
Methode 5: DELETE
Wenn eine DELETE-Methode auf eine einzelne Ressource abzielt, wird diese Ressource vollständig entfernt.
DELETE-Implementierungen sind in der Regel etwas inkonsistent: Die URL für die Ressource bleibt möglicherweise verfügbar, auch wenn die eigentliche Ressource nicht vorhanden ist. In diesem Szenario ist es möglich, dass der Server oder die Ressourcenimplementierung den Status der verschwundenen Ressource mithilfe der URL weiterhin ändert und wahrscheinlich anders auf nachfolgende DELETE-Ausführungen reagiert.
Obwohl es möglich ist, die DELETE-Methode in einer Ressourcensammlung zu verwenden, ist es im Allgemeinen am besten, sie zu vermeiden, da sie alle Inhalte löscht.
Verschiedene HTTP-Methoden
Zusätzlich zu den fünf wichtigsten HTTP-Methoden für die Entwicklung von RESTful APIs können vier weitere Methoden bei der Organisation und Optimierung von HTTP-API-basierten Anwendungen unterstützen.
Obwohl sie bei typischen Client-Server-Transaktionen selten erforderlich sind, können diese Methoden manchmal hilfreich sein, zum Beispiel bei der Entwicklung von Anwendungen, die mit Servern interagieren, die möglicherweise unterschiedliche Client-Server-Beziehungen unterstützen, oder in Situationen, in denen HTML-Inhalte auf mehrere Server verweisen.
Methode: HEAD
HEAD ist eine Methode zur Abfrage von Ressourcen-Metadaten auf dem Server. Typische Anwendungen sind die Überprüfung der Größe oder des Status einer Ressource, bevor sie mit einer anderen Methode verwendet wird. Die Antwort ist dieselbe wie bei einem GET, aber der Server gibt den Nachrichtentext nicht zurück.
Methode: OPTIONS
OPTIONS gibt eine Liste der unterstützten Methoden für die angegebene Ressource zurück, die Entwickler verwenden können, um den API-Zugriff auf die optimale Menge verfügbarer Methoden anzupassen. OPTIONS ist auch für die CORS-Vorabprüfung (Cross-Origin Resource Sharing) nützlich, um festzustellen, ob ein Server einen Methodenaufruf für eine Cross-Origin-Ressource akzeptieren würde.
Methode: TRACE
TRACE ist nützlich für die Fehlerbehebung und Überprüfung des API-Datenformats und -inhalts. Es zeigt, wie die Ziel- und Zwischenserver eine HTTP-Nachricht verarbeiten, indem sie die Nachricht so zurückgeben, wie sie empfangen wurde.
Methode: CONNECT
CONNECT fordert einen Proxy auf, einen Tunnel zu einem bestimmten Ziel einzurichten. Es kann HTTP ermöglichen, eine Sitzung in einem anderen Protokoll zu übertragen, einschließlich relativ unsicherer Protokolle wie SMTP und FTP. Seine Fähigkeit, ein anderes Protokoll zu kapseln, stellt ein Sicherheitsrisiko dar. Daher sollten Entwickler CONNECT nur verwenden, wenn es eine Karte mit sicheren Anforderungszielen gibt, auf die CONNECT verweisen kann.
