7 HTTP-Methoden, die jeder Webentwickler kennen sollte und wie man sie testet

Haben Sie sich jemals gefragt, was der Unterschied zwischen GET und POSTAnforderungen ist oder wann PUT ? Du bist nicht allein. Mit einem grundlegenden Verständnis der verschiedenen HTTP-Methoden oder Verben ist ein APIsupports ein hilfreiches Wissen beim Erkunden und Testen von APIs.

In diesem Beitrag werde ich diskutieren, wie jede HTTP-Methode verwendet wird und wie man sie in Ihre API-Tests einbezieht.

HTTP Methoden

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH
• OPTIONS

GET

GET Anfragen sind die häufigsten und am weitesten verbreiteten verwendete Methoden in APIs undWebsites. Einfach ausgedrückt, wird die GET-Methode verwendet, um Daten von einem Server an der angegebenen Ressource abzurufen. Angenommen, Sie haben einen APIwith a /users Endpunkt. Eine GET-Anforderung an diesen Endpunkt sollteeine Liste aller verfügbaren Benutzer zurückgeben.

Da eine GET-Anforderung nur Daten anfordert und keine Ressourcen ändert, wird sie als sichere und idempotente Methode betrachtet.

Testen einer API mit GET-Anfragen

Wenn Sie Tests für eine API erstellen, wird die GET -Methode wahrscheinlich seindie häufigste Art der Anfrage von Verbrauchern des Dienstes, soEs ist wichtig, jeden bekannten Endpunkt mit einer GET-Anfrage zu überprüfen.

Auf einer grundlegenden Ebene sollten diese Dinge validiert werden:

• Überprüfen Sie, ob eine gültige GET-Anforderung einen 200 Statuscode zurückgibt.
• Stellen Sie sicher, dass eine GET-Anforderung an eine bestimmte Ressource die correctdata zurückgibt. Beispiel: GET /users gibt eine Liste von Benutzern zurück.

GET ist häufig die Standardmethode in HTTP-Clients, daher sollte das Erstellen von Tests für diese Ressourcen mit jedem von Ihnen gewählten Tool einfach sein.

POST

In Webdiensten werden POST Anforderungen verwendet, um Daten an den APIserver zu senden, um eine Ressource zu erstellen oder zu udpaten. Die an den Server gesendeten Daten werden im Anforderungstext der HTTP-Anforderung gespeichert.

Das einfachste Beispiel ist ein Kontaktformular auf einer Website. Wenn Sie die Eingaben in einem Formular ausfüllen und auf Senden klicken, werden diese Daten in den Antworttext der Anforderung eingefügt und an den Server gesendet. Dies können JSON-, XML- oder Abfrageparameter sein (es gibt viele andere Formate, aber diese sind die gebräuchlichsten).

Es ist erwähnenswert, dass eine POST Anfrage nicht idempotent ist. Es mutiert Daten auf dem Backend-Server (durch Erstellen oder Aktualisieren einer Ressource), im Gegensatz zu einer GET Anforderung, die keine Daten ändert. Hier ist eine großartige Erklärung der Idempotenz.

Testen einer API mit POST-Anfragen

Die zweithäufigste HTTP-Methode, die Sie in Ihren API-Tests finden, ist POST. Wie oben erwähnt, POST Anfragen werden dazu verwendetdaten an den API-Server senden und eine Ressource erstellen oder aktualisieren. Da POST-Anforderungen Daten ändern, ist es wichtig, API-Tests für alle Ihre POST-Methoden durchzuführen.

Hier sind einige Tipps zum Testen von POST-Anfragen:

• Erstellen Sie eine Ressource mit einer POST Anfrage und stellen Sie sicher, dass ein 200 Statuscode zurückgegeben wird.
• Stellen Sie als Nächstes eine GET -Anforderung für diese Ressource und stellen Sie sicher, dass die Daten korrekt gespeichert wurden.
• Fügen Sie Tests hinzu, die sicherstellen, dass POST Anforderungen mit falschen oder schlecht formatierten Daten fehlschlagen.

Weitere Ideen zu gängigen API-Testszenarien finden Sie in diesem Beitrag.

PUT

Simlar to POST, PUT Anfragen werden verwendet, um Daten an die API toupdate zu senden oder eine Ressource zu erstellen. Der Unterschied ist,dass Output-Anforderungen idempotent sind. Das heißt, wenn Sie dieselbe PUT-Anforderung mehrmals aufrufen, wird immer dasselbe Ergebnis erzielt. Im Gegensatz dazu kann das wiederholte Aufrufen einer POST-Anforderung Nebenwirkungen haben, wenn dieselbe Ressource mehrmals erstellt wird.

Wenn eine PUT Anforderung eine Ressource erstellt, antwortet der Server im Allgemeinen mit einer 201Created), und wenn die Anforderung eine vorhandene Ressource ändert, gibt der Server eine 200OK) oder 204NoContent).

Testen einer API mit PUT-Anforderungen

Testen einer APIs PUT Methoden ist dem Testen von POSTrequests sehr ähnlich. Aber jetzt, da wir den Unterschied zwischen den beiden kennen (Idempotenz), können wir API-Tests erstellen, um dieses Verhalten zu bestätigen.

Überprüfen Sie diese Dinge, wenn Sie PUT-Anforderungen testen:

• Wiederholtes Aufrufen einer PUT Anforderung gibt immer das gleiche Ergebnis zurück(idempotent).
• Der richtige Statuscode wird beim Erstellen und Aktualisieren zurückgegebeneine Ressource (zB 201 oder 200204).
• Nach dem Aktualisieren einer Ressource mit einer PUT -Anforderung sollte eine GET -Anforderung fürdiese Ressource die richtigen Daten zurückgeben.
• PUT Anfragen sollten fehlschlagen, wenn ungültige Daten in therequest – nichts sollte aktualisiert werden.

PATCH

A PATCH request ist eine der weniger bekannten HTTP-Methoden, aber ich nehme sie so hoch in die Liste auf, da sie POST undPUT ähnelt. Der Unterschied zu PATCH besteht darin, dass Sie nur partialmodifications auf die Ressource anwenden.

Der Unterschied zwischen PATCH und PUT besteht darin, dass die PATCH-Anforderung nicht idempotent ist (wie eine POST-Anforderung).

Um die teilweise Änderung zu erweitern, sagen Sie, dass Ihre API einen/users/{{userid}} Endpunkt hat und ein Benutzer einen Benutzernamen hat. Bei einer PATCH-Anforderung müssen Sie möglicherweise nur den aktualisierten Benutzernamen im Anforderungstext senden – im Gegensatz zu POST und PUT, für die die Fulluser-Entität erforderlich ist.

Testen einer API mit PATCH-Anfragen

Da die PATCH Methode so einfach zu POSTEN und zu setzen ist, gelten viele der gleichen Testtechniken. Es ist immer noch wichtig, das Verhalten aller API-Endpunkte zu validieren, die diese Methode akzeptieren.

Worauf Sie beim Testen von PATCH-Anfragen achten sollten:

• Eine erfolgreiche PATCH Anfrage sollte einen 2xx Statuscode zurückgeben.
• PATCH Anfragen sollten fehlschlagen, wenn ungültige Daten in der Anfrage angegeben werden – nichts sollte aktualisiert werden.

Die Semantik von PATCH-Anfragen hängt weitgehend von der spezifischen API ab, die Sie testen.

DELETE

Die DELETE Methode ist genau so, wie sie sich anhört: löschen Sie die Ressource unter der angegebenen URL. Diese Methode ist eine der häufigsten in RESTfulAPIs, daher ist es gut zu wissen, wie sie funktioniert.

Testen einer API mit Löschanforderungen

DELETE Anforderungen sollten stark getestet werden, da sie im Allgemeinen Daten aus einer Datenbank entfernen. Stellen Sie sicher, dass Sie die richtigen Anmeldeinformationen verwenden und nicht mit echten Benutzerdaten testen.

Ein typischer Testfall für eine DELETE-Anfrage würde folgendermaßen aussehen:

1. Erstellen Sie einen neuen Benutzer mit einer POST Anfrage an /users
2. Erstellen Sie mit der von POST zurückgegebenen Benutzer-ID eine DELETE/users/{{userid}}
3. Eine nachfolgende GET Anfrage an /users/{{userid}} sollte einen 404 not found Statuscode zurückgeben.

Darüber hinaus sollte das Senden einer Löschanforderung an eine unbekannte Ressource einen Nicht-200-Statuscode zurückgeben.

HEAD

Die HEAD Methode ist fast identisch mit GET, außer ohne theresponse Körper. Mit anderen Worten, wenn GET /users eine Liste von zurückgibt Benutzer, dann HEAD /users wird die gleiche Anfrage stellen, aber die Liste der Benutzer nicht zurückerhalten.

HEAD-Anfragen sind nützlich, um zu überprüfen, was eine GET-Anfrage zurückgeben wird, bevor tatsächlich eine GET-Anfrage gestellt wird – wie vor dem Herunterladen einer großen Datei oder eines Responsebody. Erfahren Sie mehr über HEAD Requests auf MDN.

Es ist erwähnenswert, dass nicht jeder Endpunkt, der GET unterstützt, HEAD unterstützt – es hängt vollständig von der API ab, die Sie testen.

Testen einer API mit HEAD-Anfragen

API-Anfragen mit HEAD Methoden zu stellen, ist eigentlich eine effektive Möglichkeit, einfach zu überprüfen, ob eine Ressource verfügbar ist. Es ist eine gute Praxis, einen Test für HEAD-Anforderungen überall dort zu haben, wo Sie einen Test für GET-Anforderungen haben (solange die API dies unterstützt).

Überprüfen Sie diese Dinge, wenn Sie eine API mit HEAD-Anforderungen testen:

• Verify andcheckHTTP headers returnedfrom a HEAD request
• Machen Sie Assertions gegen den Statuscode von HEAD requests
• Testen Sie Requests mit verschiedenen Abfrageparameternr, um sicherzustellen, dass die Apirespons

Ein weiterer nützlicher Fall für HEAD Anforderungsisapi smoke testing – Stellen Sie eine HEAD-Anfrage gegen jeden API-Endpunkt, um sicherzustellen, dass sie.

OPTIONEN

Zu guter Letzt haben wir OPTIONS Anfragen. OPTIONS Requests sind einer meiner Favoriten, wenn auch nicht so weit verbreitet wie die anderen HTTPmethods. Kurz gesagt, eine OPTIONS Anforderung sollte Daten zurückgeben, die beschreiben, welche anderen Methoden und Vorgänge der Server unter der angegebenen URL unterstützt.

OPTIONS-Requests werden lockerer definiert und verwendet als die anderen, was sie zu einem guten Kandidaten macht, um auf schwerwiegende API-Fehler zu testen. Wenn anAPI keine OPTIONS-Anfrage erwartet, ist es gut, einen Testfall zu platzieren, der das fehlgeschlagene Verhalten überprüft.

Testen einer API mit OPTIONS Requests

Testen einer OPTIONS Anforderung ist vom Webdienst abhängig; ob es das unterstützt oder nicht und was zurückkehren soll, wird definierenwie Sie es testen sollten.

So validieren Sie einen Endpunkt mithilfe von OPTIONEN:

• Überprüfen Sie in erster Linie die Antwortheader und den Statuscode der Anforderung
• Testen Sie Endpunkte, die keine OPTIONEN unterstützen, und stellen Sie sicher, dass sie fehlschlagen

Weitere Ressourcen

Was ich oben besprochen habe, ist nur ein Ausgangspunkt, um in toHTTP-Methoden zu graben und verschiedene Ressourcen einer API zu testen. Es geht auch von einem meist idealen Fall aus – in der realen Welt sind APIs nicht so strukturiert wie die obigen Beispiele. Dies macht das Testen verschiedener Methoden gegen einen APIan effektiv, um unerwartete Fehler zu finden.