7 HTTP-methoden elke webontwikkelaar zou moeten weten en hoe hij ze moet testen

ooit afgevraagd wat het verschil is tussen GET en POSTVerzoeken, of wanneer PUT? Je bent niet alleen. Het hebben van een basisbegrip van de verschillende HTTP methoden, of werkwoorden, een APIsupports is een nuttige kennis bij het verkennen en testen van API ‘ s.

In dit bericht zal ik bespreken hoe elke HTTP-methode wordt gebruikt en hoe ze in uw API-testen kunnen worden opgenomen.

HTTP

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

KOMEN

GET aanvragen zijn de meest voorkomende en meest gebruikte methoden in Api ‘ s andwebsites. Simpel gezegd, de GET methode wordt gebruikt om gegevens terug te trekken van een server op de opgegeven bron. Bijvoorbeeld, stel dat je een API hebt met een /users eindpunt. Het maken van een GET request naar dat eindpunt moet een lijst van alle beschikbare gebruikers draaien.

aangezien een GET-verzoek alleen gegevens opvraagt en geen resources wijzigt, wordt het beschouwd als een veilige en idempotente methode.

het testen van een API met GET requests

wanneer u tests maakt voor een API, zal de methode GET waarschijnlijk het meest voorkomende type verzoek zijn dat door consumenten van de service wordt gedaan, dus het is belangrijk om elk bekend eindpunt te controleren met een GET request.

op basisniveau moeten deze dingen worden gevalideerd:

• Controleer of een geldig GET-verzoek een 200 statuscode retourneert.
• zorg ervoor dat een GET-verzoek naar een specifieke bron de juiste gegevens retourneert. Bijvoorbeeld, GET /users geeft een lijst van gebruikers terug.

GET is vaak de standaardmethode in HTTP-clients, dus het maken van testen voor deze bronnen moet eenvoudig zijn met elk gereedschap dat u kiest.

POST

In webservices worden POST Verzoeken gebruikt om gegevens naar de APIserver te sturen om een bron aan te maken of te udperen. De gegevens die naar de server worden verzonden, worden opgeslagen in de aanvraagtekst van het HTTP-verzoek.

het eenvoudigste voorbeeld is een contactformulier op een website. Wanneer u de invoer in een formulier invult en op Verzenden klikt, worden die gegevens in het antwoordveld van het verzoek gezet en naar de server verzonden. Dit misschien JSON, XML, of query parameters (er zijn tal van andere formaten,maar deze zijn de meest voorkomende).

Het is vermeldenswaard dat een POST verzoek niet-idempotent is. Itmuteert gegevens op de backend server (door aresource aan te maken of bij te werken), in tegenstelling tot een GET verzoek dat geen gegevens verandert. Hier is een grote verklaring van idempotentcy.

het testen van een API met POSTVERZOEKEN

de tweede meest voorkomende HTTP methode die u zult tegenkomen in uw API testsis POST. Zoals hierboven vermeld, worden POST Verzoeken gebruikt om gegevens naar de API-server te sturen en een bron te maken of bij te werken. SincePOST Verzoeken gegevens te wijzigen, het is belangrijk om API-tests voor alof uw POST methoden.

Hier zijn enkele tips voor het testen van postverzoeken:

• Maak een bron aan met een POST verzoek en zorg ervoor dat een 200 statuscode wordt geretourneerd.
• maak vervolgens eenGET verzoek voor die bron, en zorg ervoor dat de gegevens correct zijn opgeslagen.
• voeg tests toe die ervoor zorgen dat POST Verzoeken mislukken met onjuiste of slecht geformatteerde gegevens.

voor meer ideeën over gemeenschappelijke API testingscenarios,kijk op dit bericht.

plaats

Simlar om te posten, PUT verzoeken worden gebruikt om gegevens naar de API toupdate te verzenden of een bron aan te maken. Het verschil is dat uitvoerverzoeken idempotent zijn. Datis, het aanroepen van dezelfde PUT verzoek meerdere keren zal altijd hetzelfde resultaat te produceren. In tegenstelling, het aanroepen van een bericht verzoek herhaaldelijk makehave bijwerkingen van het creëren van dezelfde bron meerdere keren.

over het Algemeen, wanneer een PUT aanvraag creëert een bron op de server willrespond met een 201Created), en indien de aanvraag modifiesexisting resource retourneert de server een 200OK) of 204NoContent).

het testen van een API met PUT requests

het testen van een API PUT methoden is zeer vergelijkbaar met het testen van POSTrequests. Maar nu we het verschil tussen de twee weten(idempotency), kunnen we API-tests maken om dit gedrag te bevestigen.

Controleer op deze dingen bij het testen van PUT-aanvragen:

• herhaaldelijk aanroepen van een PUT verzoek geeft altijd hetzelfde resultaat(idempotent).
• de juiste statuscode wordt geretourneerd bij het aanmaken en bijwerken van een bron (bijvoorbeeld 201 of 200204).
• na het bijwerken van een bron met een PUT verzoek, a GET verzoek voordat bron de juiste gegevens moet retourneren.
• PUT verzoeken zouden moeten mislukken als ongeldige gegevens worden opgegeven in de vraag — nothing zou moeten worden bijgewerkt.

PATCH

A PATCH verzoek is een van de minder bekende HTTP-methoden, maar ik sluit het zo hoog in de lijst omdat het vergelijkbaar is met POST andPUT. Het verschil met PATCH is dat u alleen partiële wijzigingen op de bron toepast.

het verschil tussen PATCH en PUT is dat een patch-verzoek niet-idempotent is (zoals een POST-verzoek).

om uit te breiden op gedeeltelijke wijziging, stel dat je API een/users/{{userid}} eindpunt heeft, en een gebruiker heeft een gebruikersnaam. Met aPATCH request, hoeft u misschien alleen maar de bijgewerkte Gebruikersnaam te verzenden in het aanvraagorgaan – in tegenstelling tot plaatsen en plaatsen die de volledige entiteit vereisen.

het testen van een API met PATCH requests

aangezien dePATCH methode zo eenvoudig is om te plaatsen en te plaatsen, zijn veel van dezelfde testtechnieken van toepassing. Het is nog steeds belangrijk om het gedrag van API-eindpunten die deze methode accepteren te valideren.

waarnaar moet worden gezocht bij het testen van PATCHAANVRAGEN:

• een succesvolle PATCH verzoek moet een 2xx statuscode retourneren.
• PATCH verzoeken zouden moeten mislukken als ongeldige gegevens worden opgegeven in de vraag — niets zou moeten worden bijgewerkt.

de semantiek van PATCHAANVRAGEN zal grotendeels afhangen van de specifieke API die u test.

DELETE

de DELETE methode is precies zoals het klinkt: verwijder de bron op de opgegeven URL. Deze methode is een van de meest voorkomende in RESTfulAPIs dus het is goed om te weten hoe het werkt.

het testen van een API met VERWIJDERVERZOEKEN

DELETE verzoeken moeten zwaar worden getest omdat ze over het algemeen gegevens uit een database verwijderen. Wees voorzichtig bij het testen van DELETE methoden, makesure u gebruikt de juiste referenties en niet testen met realuser gegevens.

een typische testcase voor een verwijderingsverzoek ziet er zo uit:

1. Maak een nieuwe gebruiker aan met een POST aanvraag /users
2. de gebruikers-id geretourneerd van de POST, het maken van een DELETE aanvraag /users/{{userid}}
3. Een latere GET aanvraag /users/{{userid}} terug moet keren een 404 status code.

bovendien moet het verzenden van een verwijderingsverzoek naar een onbekende bron geen statuscode van niet-200 zijn.

HEAD

deHEAD methode is vrijwel identiek aanGET, behalve zonder de bijbehorende inhoud. Met andere woorden, als GET /users een lijst van gebruikers retourneert, dan zal HEAD /users hetzelfde verzoek doen, maar de lijst van gebruikers niet terugkrijgen.

Head-verzoeken zijn handig om te controleren wat een GET-verzoek zal worden teruggestuurd voordat een GET-verzoek daadwerkelijk wordt gedaan — zoals voordat een groot bestand of responsebody wordt gedownload. Meer informatie over HEAD-aanvragen op MDN.

Het is de moeite waard erop te wijzen dat niet elk eindpunt dat Get ondersteunt HEAD ondersteunt – het hangt volledig af van de API die je test.

het testen van een API met head requests

het maken van API-requests met HEAD methoden is eigenlijk een effectieve manier om eenvoudig te controleren of een bron beschikbaar is. Het is goodpractice om een test voor HEAD Verzoeken overal heb je een test voor verzoeken krijgen (zolang de API ondersteunt).

controleer deze dingen bij het testen van een API met head requests:

• Verify andcheckHTTP headers returned from a head request
• assertions against the status code of head requests
• Test requests with various query parametesr to ensure the Apirerespons

Another useful case forHEAD requestsisAPI smoke testing-doe een head request tegen elke API endpoint to ensure they beschikbaar.

opties

Last but not least hebben we OPTIONS Verzoeken. Opties Verzoeken zijneen van mijn favorieten, maar niet zo veel gebruikt als de andere HTTPmethods. In een notendop, een OPTIONS request moet datadescribe welke andere methoden en bewerkingen de server ondersteunt op de gegeven URL terug te keren.

OPTIEAANVRAGEN zijn losser gedefinieerd en gebruikt dan de andere,waardoor ze een goede kandidaat zijn om te testen op fatale API-fouten. Als anAPI geen OPTIEVERZOEK verwacht, Is het goed om een testcaseïneplaats te plaatsen die falend gedrag verifieert.

het testen van een API met opties aanvragen

het testen van een OPTIONS aanvraag is afhankelijk van de webservice; of het dat ondersteunt of niet en wat er wordt verondersteld terug te keren zal definehowhoe je het moet testen.

hoe valideer je een eindpunt met behulp van opties:

• controleer vooral de responskoppen en statuscode van het verzoek
• Test endpoints die geen opties ondersteunen, en zorg ervoor dat ze niet correct

meer bronnen

wat ik hierboven heb besproken is slechts een startpunt voor het graven in toHTTP-methoden en het testen van verschillende bronnen van een API. Het veronderstelt ook een meestal ideaal geval-in de echte wereld, API ‘ s zijn niet zo gestructureerd alsde voorbeelden hierboven. Dit maakt het testen van verschillende methoden tegen een APIan effectieve manier om onverwachte bugs te vinden.