någonsin undrat vad skillnaden är mellan GET och POSTförfrågningar, eller när man ska använda PUT? Du är inte ensam. Att ha en grundläggande förståelse för de olika HTTP-metoderna, eller verb, är en APIsupports en användbar kunskap när man utforskar och testar API: er.
i det här inlägget diskuterar jag hur varje HTTP-metod används och hur maninkorporerar dem i din API-testning.
HTTP-metoder
GETPOSTPUTHEADDELETEPATCHOPTIONS
hämta
GET – förfrågningar är de vanligaste och mest använda metoderna i API: er ochwebbplatser. Enkelt uttryckt används GET-metoden för att återställa data från aserver vid den angivna resursen. Säg till exempel att du har en Apimed en /users slutpunkt. Att göra en GET-förfrågan till den slutpunkten böråtervända en lista över alla tillgängliga användare.
eftersom en GET-begäran endast begär data och inte ändrar anyresources, anses den vara en säker och idempotent metod.
testa ett API med GET-förfrågningar
När du skapar tester för ett API kommer metoden GET sannolikt att vara den vanligaste typen av begäran från konsumenter av tjänsten, så det är viktigt att kontrollera alla kända slutpunkter med en GET-begäran.
på en grundläggande nivå bör dessa saker valideras:
- kontrollera att en giltig GET-begäran returnerar en
200statuskod. - se till att en GET begäran till en viss resurs returnerar correctdata. Till exempel returnerar
GET /usersen lista med användare.
GET är ofta standardmetoden i HTTP-klienter, så att skapa testför dessa resurser ska vara enkelt med vilket verktyg du väljer.
POST
i webbtjänster används POST förfrågningar för att skicka data till Apiservern för att skapa eller udpate en resurs. De data som skickas till servern lagras i HTTP-begäran.
det enklaste exemplet är ett kontaktformulär på en webbplats. När du fyller i ingångarna i ett formulär och trycker på Skicka, läggs dessa data in i svarskroppen för begäran och skickas till servern. Detta kanske JSON, XML eller query parametrar (det finns gott om andra format, men dessa är de vanligaste).
det är värt att notera att en POST begäran är icke-idempotent. Itmutates data på backend-servern (genom att skapa eller uppdatera aresource), i motsats till en GET begäran som inte ändrar anydata. Här är en bra förklaring av idempotentcy.
testa ett API med POST-förfrågningar
den näst vanligaste HTTP-metoden du kommer att stöta på i dina API-testär POST. Som nämnts ovan användsPOST – förfrågningar tillskicka data till API-servern och skapa eller uppdatera en resurs. Eftersom postförfrågningar ändrar data är det viktigt att ha API-tester för alla dina POSTMETODER.
här är några tips för att testa postförfrågningar:
- skapa en resurs med en
POSTbegäran och se till att en200statuskod returneras. - gör sedan en
GETbegäran om den resursen och se till att data sparades korrekt. - Lägg till tester som säkerställer
POSTförfrågningar misslyckas med felaktiga eller dåligt formaterade data.
För några fler ideer om vanliga API-testscenarier, kolla in det här inlägget.
sätt
Simlar att posta, PUT förfrågningar används för att skicka data till API toupdate eller skapa en resurs. Skillnaden isthatPUT-förfrågningar är idempotenta. Att ringa samma PUT-förfrågan flera gånger kommer alltid att producerasamma resultat. Däremot ringer en postförfrågan upprepade gångerhar biverkningar av att skapa samma resurs flera gånger.
generellt, när enPUT begäran skapar en resurs servern kommer att svara med en201Created), och om begäran modifierasexisting resurs servern kommer att returnera en200OK) eller204NoContent).
testa ett API med PUT-förfrågningar
Testa en API: er PUT metoder är mycket lik att testa POSTrequests. Men nu när vi vet skillnaden mellan de två(idempotency) kan vi skapa API-tester för att bekräfta detta beteende.
kontrollera efter dessa saker när du testar PUT-förfrågningar:
- upprepade gånger anropar en
PUTrequest returnerar alltid samma resultat(idempotent). - den korrekta statuskoden returneras när du skapar och uppdaterar en resurs (t.ex.
201eller200204). - efter uppdatering av en resurs med en
PUTbegäran, enGETbegäran omDen resursen ska returnera rätt data. -
PUTbegäranden ska misslyckas om ogiltiga data tillhandahålls i förfrågan-ingenting ska uppdateras.
PATCH
a PATCH begäran är en av de mindre kända HTTP-metoderna, men jag inkluderar det så högt i listan eftersom det liknar POST andPUT. Skillnaden med PATCH är att du bara tillämpar partiella ändringar på resursen.
skillnaden mellan PATCH och PUT är thataPATCH request är icke-idempotent (somen postförfrågan).
för att expandera på partiell modifiering, säg att du är API har en/users/{{userid}} slutpunkt, och en användare har ett användarnamn. Med aPATCH request kan du bara behöva skicka det uppdaterade användarnamnet i begäran – i motsats till POST och PUT som kräver fullluser-enheten.
testa ett API med PATCHFÖRFRÅGNINGAR
eftersomPATCH – metoden är så simlar att posta och sätta, gäller många av samma testtekniker. Det är fortfarande viktigt att validera beteende för alla API-slutpunkter som accepterar den här metoden.
vad du ska leta efter när du testar PATCHFÖRFRÅGNINGAR:
- en framgångsrik
PATCHbegäran ska returnera en2xxstatuskod. -
PATCHförfrågningar bör misslyckas om ogiltiga data tillhandahålls i therequest-ingenting bör uppdateras.
semantiken för PATCHFÖRFRÅGNINGAR beror till stor del på det specifika API du testar.
ta bort
DELETE metoden är precis som den låter: ta bort resursen vidden angivna webbadressen. Denna metod är en av de vanligaste i RESTfulAPIs så det är bra att veta hur det fungerar.
testa ett API med DELETE-förfrågningar
DELETE – förfrågningar bör testas kraftigt eftersom de i allmänhet tar bort data från en databas. Var försiktig när du testar DELETE metoder, makesure du använder rätt referenser och inte testa med realuser data.
ett typiskt testfall för en RADERINGSFÖRFRÅGAN skulle se ut så här:
- skapa en ny användare med en
POSTbegäran till/users - med användar-id returneras från
POST, gör enDELETEbegäran till/users/{{userid}} - en efterföljande
GETbegäran till/users/{{userid}}ska returnera en 404 ej hittad statuskod.
dessutom skickar en RADERINGSFÖRFRÅGAN till en okänd resurs böråtervända icke-200 statuskod.
HEAD
HEAD metoden är nästan identisk med GET, förutom utan svarskropp. Med andra ord, om GET /users returnerar en lista över användare, kommer HEAD /users att göra samma förfrågan men kommer inte att få tillbaka listan över användare.
HEAD förfrågningar är användbara för att kontrollera vad en GET begäran willreturn innan faktiskt gör en GET begäran-som beforedownloading en stor fil eller responsebody. Läs mer om HEAD-förfrågningar på MDN.
det är värt att påpeka att inte alla slutpunkter som stöder GETwill stöder HEAD – det beror helt på det API du testar.
testa ett API med HUVUDFÖRFRÅGNINGAR
att göra API-förfrågningar med HEAD metoder är faktiskt ett effektivt sätt att helt enkelt verifiera att en resurs är tillgänglig. Det är brapractice att ha ett test för HUVUDFÖRFRÅGNINGAR överallt där du har ett test för att få förfrågningar (så länge API stöder det).
kontrollera dessa saker när du testar ett API med HUVUDFÖRFRÅGNINGAR:
- verifiera andcheckhttp-rubriker returnedfrom en HUVUDFÖRFRÅGAN
- gör påståenden mot statuskoden för HUVUDFÖRFRÅGNINGAR
- Testförfrågningar med olika frågeparameterr för att säkerställa API-svaren
ett annat användbart fall förHEAD requestsisAPI smoke testing-gör en HUVUDFÖRFRÅGAN mot varje API-slutpunkt för att säkerställa att de tillgänglig.
alternativ
sist men inte minst har viOPTIONS förfrågningar. ALTERNATIVFÖRFRÅGNINGAR ären av mina favoriter, men inte lika mycket som de andra HTTPmethods. I ett nötskal bör en ALTERNATIVFÖRFRÅGAN returnera databeskriva vilka andra metoder och operationer servern stödervid den angivna webbadressen.
ALTERNATIVFÖRFRÅGNINGAR är mer löst definierade och används än de andra,vilket gör dem till en bra kandidat för att testa för dödliga API-fel. Om anAPI inte förväntar sig en ALTERNATIVFÖRFRÅGAN är det bra att sätta ett testkaseinplats som verifierar felaktigt beteende.
testa ett API med ALTERNATIVFÖRFRÅGNINGAR
Testa ett OPTIONS begäran är beroende av webbtjänsten; oavsett om det inte stöder det och vad som ska återvända kommer definierahur du ska testa det.
Så här validerar du en slutpunkt med alternativ:
- kontrollera först svarhuvuden och statuskoden för begäran
- Teständpunkter som inte stöder alternativ och se till att de misslyckas
fler resurser
vad jag har diskuterat ovan är bara en utgångspunkt för att gräva i toHTTP-metoder och testa olika resurser i ett API. Det antar ocksåett mestadels idealiskt fall-i den verkliga världen är API: er inte lika strukturerade somexemplen ovan. Detta gör att testa olika metoder mot en APIan effektivt sätt att hitta oväntade buggar.