har du nogensinde spekuleret på, hvad forskellen er mellemGET ogPOSTanmodninger, eller hvornår skal du brugePUT? Du er ikke alene. At have en grundlæggende forståelse af de forskellige HTTP-metoder, eller verb, en APIsupports er en nyttig viden, når man udforsker og tester API ‘ er.
i dette indlæg vil jeg diskutere, hvordan hver HTTP-metode bruges, og hvordan man inkorporerer dem i din API-test.
HTTP metoder
GETPOSTPUTHEADDELETEPATCH-
OPTIONS
Get
GET anmodninger er de mest almindelige og udbredte metoder i API ‘ er og internetsider. Kort sagt, GET-metoden bruges til at gendanne data fra aserver ved den angivne ressource. Sig for eksempel, at du har en Apimed et /users endepunkt. At lave en GET-anmodning til dette slutpunkt skalreturnere en liste over alle tilgængelige brugere.
da en GET-anmodning kun anmoder om data og ikke ændrer nogen ressourcer, betragtes den som en sikker og idempotent metode.
test af en API med GET-anmodninger
når du opretter test for en API, vilGET – metoden sandsynligvis væreden hyppigste type anmodning fra forbrugere af tjenesten, såDet er vigtigt at kontrollere alle kendte slutpunkter med en GET-anmodning.
på et grundlæggende niveau skal disse ting valideres:
- Kontroller, at en gyldig GET-anmodning returnerer en
200statuskode. - sørg for, at en GET-anmodning til en bestemt ressource returnerer de korrekte data. For eksempel
GET /usersreturnerer en liste over brugere.
GET er ofte standardmetoden i HTTP-klienter, så oprettelse af testfor disse ressourcer skal være enkel med ethvert værktøj, du vælger.
POST
i internettjenester brugesPOST anmodninger til at sende data til Apiserveren for at oprette eller udpate en ressource. De data, der sendes til serveren, gemmes i HTTP-anmodningens anmodning.
det enkleste eksempel er en kontaktformular på en hjemmeside. Når du udfylder inputene i en formular og trykker på Send, placeres disse data i anmodningens svarlegeme og sendes til serveren. Der er masser af andre formater,men disse er de mest almindelige).
det er værd at bemærke, at enPOST anmodning er ikke-idempotent. Itmutates data på backend serveren (ved at oprette eller opdatere aresource), i modsætning til en GET anmodning, som ikke ændrer anydata. Her er en god forklaring på idempotentcy.
test af en API med POSTANMODNINGER
den næst mest almindelige HTTP-metode, du støder på i din API-testsisPOST. Som nævnt ovenfor, POST anmodninger bruges tilsend data til API-serveren og opret eller Opdater en ressource. Da POST-anmodninger ændrer data, er det vigtigt at have API-test for allof dine POST-metoder.
Her er nogle tip til test af POSTANMODNINGER:
- Opret en ressource med en
POSTanmodning og sørg for, at en200statuskode returneres. - lav derefter en
GETanmodning om denne ressource, og sørg for, at dataene blev gemt korrekt. - Tilføj test, der sikrer
POSTanmodninger mislykkes med forkerte eller dårligt formaterede data.
for nogle flere ideer om fælles API testingscenarier,tjek dette indlæg.
PUT
Simlar til POST,PUT anmodninger bruges til at sende data til API toupdate eller oprette en ressource. Forskellen isthatPUT anmodninger er idempotent. Det er, at kalde den samme PUT-anmodning flere gange vil altid producere det samme resultat. I modsætning hertil ringer en POSTANMODNING gentagne gangehar bivirkninger ved at oprette den samme ressource flere gange.
generelt, når en PUT anmodning opretter en ressource serveren vil svare med en 201Created), og hvis anmodningen ændrer eksisterende ressource serveren vil returnere en 200OK) eller 204NoContent).
test af en API med PUT-anmodninger
Test af en API ‘ erPUT metoder ligner meget test af Postanmodninger. Men nu hvor vi kender forskellen mellem de to(idempotency), kan vi oprette API-test for at bekræfte denne adfærd.
kontroller for disse ting, når du tester PUT-anmodninger:
- gentagne gange at kalde en
PUTanmodning returnerer altid det samme resultat(idempotent). - den korrekte statuskode returneres, når du opretter og opdatereren ressource (f.eks
201eller200204). - efter opdatering af en ressource med en
PUTanmodning, enGETanmodning omden ressource skal returnere de korrekte data. -
PUTanmodninger skal mislykkes, hvis der leveres ugyldige data i anmodningen-intet skal opdateres.
PATCH
APATCH anmodning er en af de mindre kendte HTTP-metoder, men jeg inkluderer det så højt på listen, da det ligner POST andPUT. Forskellen med PATCH er, at du kun anvender partialmodifikationer til ressourcen.
forskellen mellem PATCH og PUT er detapatch-anmodning er ikke-idempotent (somen POST-anmodning).
for at udvide den delvise ændring skal du sige, at du API har et/users/{{userid}} endepunkt, og en bruger har et brugernavn. Med aPATCH-anmodning behøver du muligvis kun at sende det opdaterede brugernavn i anmodningsorganet – i modsætning til POST og PUT, som kræver fulluser-enheden.
test af en API med PATCH-anmodninger
siden PATCH metoden er så simlar at sende og sætte, mange afsamme testteknikker gælder. Det er stadig vigtigt at validere adfærd for eventuelle API-slutpunkter, der accepterer denne metode.
Hvad skal man se efter, når man tester PATCH-anmodninger:
- en vellykket
PATCHanmodning skal returnere en2xxstatuskode. -
PATCHanmodninger skal mislykkes, hvis der leveres ugyldige data i anmodningen-intet skal opdateres.
semantikken for PATCH-anmodninger afhænger i vid udstrækning af den specifikke API, du tester.
slet
DELETE metoden er præcis som det lyder: slet ressourcen påden angivne URL. Denne metode er en af de mere almindelige i RESTfulAPIs, så det er godt at vide, hvordan det fungerer.
test af en API med SLETNINGSANMODNINGER
DELETE anmodninger skal testes stærkt, da de generelt fjerner data fra en database. Vær forsigtig, når du tester SLETNINGSMETODER, sørg for, at du bruger de korrekte legitimationsoplysninger og ikke tester med realuser-data.
en typisk testsag for en SLETNINGSANMODNING ville se sådan ud:
- Opret en ny bruger med en
POSTanmodning til/users - med Bruger-id returneret fra
POST, lav enDELETEanmodning til/users/{{userid}} - en efterfølgende
GETanmodning til/users/{{userid}}skal returnere en 404 ikke fundet statuskode.
Hertil kommer, at sende en SLETNINGSANMODNING til en ukendt ressource shouldreturna ikke-200 statuskode.
hoved
HEAD metoden er næsten identisk medGET, undtagen udensvar krop. Med andre ord, hvis GET /users returnerer en liste overbrugere, så HEAD /users vil gøre den samme anmodning, men vil ikke komme tilbage listen over brugere.
hovedanmodninger er nyttige til at kontrollere, hvad en GET-anmodning vil vende tilbage, før du faktisk foretager en GET-anmodning-som før du henter en stor fil eller responsbody. Lær mere om HOVEDANMODNINGER på MDN.
det er værd at påpege, at ikke alle slutpunkter, der understøtter Getvil support HEAD – det afhænger helt af den API, du tester.
test af en API med HOVEDANMODNINGER
gør API-anmodninger medHEAD metoder er faktisk en effektiv mådeaf blot at kontrollere, at en ressource er tilgængelig. Det er godtpraksis at have en test for HOVEDANMODNINGER overalt, hvor du har en testfor at få anmodninger (så længe API understøtter det).
kontroller disse ting, når du tester en API med HOVEDANMODNINGER:
- Bekræft ogcheckhttp-overskrifter returneretfra en HOVEDANMODNING
- lav påstande mod statuskoden for HOVEDANMODNINGER
- Testanmodninger med forskellige forespørgselsparameterr for at sikre APIresponds
en anden nyttig sag til HEAD anmodningsisapi røgtest-lav en HOVEDANMODNING mod hvert API-slutpunkt for at sikre, at de er tilgængelige.
indstillinger
Sidst men ikke mindst har viOPTIONS anmodninger. Indstillinger anmodninger eren af mine favoritter, men ikke så udbredt som de andre HTTPmethods. I en nøddeskal skal en INDSTILLINGSANMODNING returnere databeskriver hvilke andre metoder og operationer serveren understøtterpå den givne URL.
OPTIONSANMODNINGER er mere løst defineret og brugt end de andre,hvilket gør dem til en god kandidat til at teste for fatale API-fejl. Hvis anAPI ikke forventer en OPTIONSANMODNING, er det godt at placere et testkaseinsted, der verificerer svigtende adfærd.
test af en API med OPTIONSANMODNINGER
Test af en OPTIONS anmodning er afhængig af internettjenesten; uanset om det eller ej understøtter det, og hvad der skal vende tilbage, vil definerehvordan du skal teste det.
sådan valideres et slutpunkt ved hjælp af indstillinger:
- kontroller primært svaroverskrifterne og statuskoden for anmodningen
- Test slutpunkter, der ikke understøtter indstillinger, og sørg for, at de fejler passende
flere ressourcer
det, jeg har diskuteret ovenfor, er kun et udgangspunkt for at grave i toHTTP-metoder og teste forskellige ressourcer i en API. Det antager også et stort set ideelt tilfælde-i den virkelige verden er API ‘ er ikke så strukturerede som eksemplerne ovenfor. Dette gør test af forskellige metoder mod en APIan effektiv måde at finde uventede fejl på.