přemýšleli jste Někdy, jaký je rozdíl mezi GETPOSTžádosti, nebo když na používání PUT? Nejsi sám. Mít základní pochopení různých metod HTTP, nebo slovesa, APIsupports je užitečné znalosti při zkoumání a testování API.
V tomto příspěvku, budu diskutovat o tom, jak každý HTTP metoda se používá a jak tam je ve vašem API testování.
HTTP Metody,
GETPOSTPUTHEADDELETEPATCHOPTIONS
GET požadavky jsou nejběžnější a široce používané metody v Api andwebsites. Jednoduše řečeno, metoda GET se používá k obnovení dat z aserveru na zadaný zdroj. Řekněme například, že máte APIwith /users koncový bod. Vytvoření požadavku GET do tohoto koncového bodu by mělovrátit seznam všech dostupných uživatelů.
protože požadavek GET vyžaduje pouze data a nemění žádné zdroje, je to bezpečná a idempotentní metoda.
Testování API s GET požadavky
Při vytváření testů pro API, GET metoda bude pravděpodobně ten nejčastější typ žádost spotřebitele služby, takže je důležité zkontrolovat všechny známé endpoint s GET požadavek.
Na základní úrovni, tyto věci by měly být validovány:
- Zkontrolujte, zda platný požadavek GET vrátí
200stavový kód. - ujistěte se, že požadavek GET ke konkrétnímu prostředku vrátí correctdata. Například
GET /usersvrací seznam uživatelů.
GET je často výchozí metoda v HTTP klientech, takže vytváření testsfor těchto zdrojů by mělo být jednoduché s jakýmkoli nástrojem, který si vyberete.
POST
webové služby POST žádosti jsou použity k odesílání dat do APIserver vytvořit nebo udpate zdroj. Data odeslaná na server jsou uložena v požadovaném těle požadavku HTTP.
nejjednodušším příkladem je kontaktní formulář na webové stránce. Když vyplníte vstupy ve formuláři a stisknete odeslat, tato data jsou vložena do těla odpovědi požadavku a odeslána na server. To možná JSON, XML, nebo parametry dotazu (existuje spousta jiných formátů, ale ty jsou nejčastější).
stojí za zmínku, že požadavek POST není idempotentní. Itmutates data na backend serveru (vytvořením nebo aktualizací aresource), na rozdíl od požadavku GET, který nemění anydata. Zde je skvělé vysvětlení idempotentcy.
testování API s POST požadavky
druhá nejběžnější metoda HTTP, se kterou se setkáte v testech API POST. Jak bylo uvedeno výše, POST požadavky se používajíposlat data na server API a vytvořit nebo aktualizovat zdroj. Vzhledem k tomu, že žádosti o příspěvek upravují data, je důležité mít testy API pro všechny vaše metody POST.
Zde jsou některé tipy pro testování POST požadavky:
- Vytvořit zdroj s
POSTžádost a zajistí200kód stavu vrácena. - dále proveďte
GETpožadavek na tento zdroj a ujistěte se, že data byla uložena správně. - přidejte testy, které zajistí, že požadavky
POSTselžou s nesprávnými nebo špatně formátovanými daty.
pro některé další nápady na společné API testingscenarios, podívejte se na tento příspěvek.
PUT
Simlar to POST, PUT požadavky se používají k odesílání dat do API toupdate nebo k vytvoření zdroje. Rozdíl ježe požadavky na zadání jsou idempotentní. To je, volání stejného požadavku PUT vícekrát bude vždy produkovatstejný výsledek. Naproti tomu volání požadavku POST opakovaně provádímají vedlejší účinky při vytváření stejného zdroje vícekrát.
Obecně platí, že když PUT žádost vytváří zdrojů serveru willrespond s 201Created), a pokud žádost modifiesexisting resource server vrátí 200OK) nebo 204NoContent).
Testování API s DÁT požadavky
Testování Api PUT metody je velmi podobné testování POSTrequests. Ale teď, když známe rozdíl mezi těmito dvěma (idempotency), můžeme vytvořit testy API pro potvrzení tohoto chování.
Zkontrolujte, zda tyto věci při testování DÁT požadavky:
- Opakovaně volá
PUTžádost vždy vrátí stejný výsledek(idempotentní). - správný stavový kód je vrácena při vytváření a updatinga zdrojů (např
201nebo200204). - Po aktualizaci zdrojů s
PUTžádost,GETžádost ano zdroj by se měl vrátit správná data. -
PUTpožadavky by měly selhat, pokud jsou v nich zadána neplatná data-nic by se nemělo aktualizovat.
PATCH
a PATCH požadavek je jednou z méně známých metod HTTP, ale v seznamu ji považuji za tak vysokou, protože je podobná POST andPUT. Na rozdíl od PATCH je, že můžete použít pouze partialmodifications zdrojů.
rozdíl mezi patchem a PUT je ten, žežádost o Patch není idempotentní (jako požadavek na POST).
Chcete-li rozšířit částečnou modifikaci, řekněme, že jste API má/users/{{userid}} koncový bod A Uživatel má uživatelské jméno. S aPATCH request, možná budete muset odeslat aktualizované uživatelské jméno pouze v těle žádosti-na rozdíl od POST a PUT, které vyžadují entitu fulluser.
Testování API s PATCHEM požadavky
, Protože PATCH metoda je tak simlar POST a PUT, mnoho stejných technik testování použít. Je stále důležité ověřitchování všech koncových bodů API, které tuto metodu akceptují.
Co hledat při testování požadavků na opravu:
- úspěšný
PATCHpožadavek by měl vrátit2xxstavový kód. -
PATCHpožadavky by měly selhat, pokud jsou v therequestu dodána neplatná data-nic by nemělo být aktualizováno.
sémantika požadavků na opravu bude do značné míry záviset na konkrétním API, které testujete.
smazat
DELETE metoda je přesně tak, jak zní: odstraňte zdroj na adresezadanou adresu URL. Tato metoda je jednou z běžnějších v RESTfulAPIs, takže je dobré vědět, jak to funguje.
Testování API s DELETE požadavky
DELETE žádosti by měly být těžce zkoušena, protože oni obecně removedata z databáze. Při testování metod mazání buďte opatrní, ujistěte se, že používáte správná pověření a netestujete s daty realuser.
typický testovací případ pro požadavek na odstranění by vypadal takto:
- Vytvořit nového uživatele
POSTpožadavek na/users - S id uživatele vrátil z
POST, abyDELETEpožadavek na/users/{{userid}} - následující
GETpožadavek na/users/{{userid}}by se měla vrátit 404 not found status kód.
kromě toho by odeslání požadavku na odstranění neznámého zdroje mělo být změněno na stavový kód non-200.
HEAD metoda je téměř totožná s GET, ale bez theresponse tělo. Jinými slovy, pokud GET /users vrátí seznam ofusers, pak HEAD /users bude mít stejnou žádost, ale nebude se dali znovu seznam uživatelů.
HEAD požadavky jsou užitečné pro kontrolu toho, co GET request willreturn před skutečně dělat GET request-jako beforedownloading velký soubor nebo responsebody. Další informace o požadavcích na hlavu na MDN.
je třeba zdůraznit, že ne každý koncový bod, který podporuje GETwill support HEAD-to zcela závisí na API, které testujete.
Testování API s HLAVOU požadavky
API HEAD metody je skutečně efektivní způsob jak jednoduše ověřit, že zdroj je k dispozici. Je dobré mít test na požadavky hlavy všude, kde máte testfor GET požadavky (pokud to API podporuje).
zkontrolujte tyto věci při testování API s požadavky HEAD:
- Ověření andcheckHTTP záhlaví returnedfrom požadavek HEAD
- Aby tvrzení proti status kód z HLAVY žádosti
- Test žádostí s různými dotaz parametesr zajistit APIresponds
Další užitečné pouzdro pro HEAD requestsisAPI kouř testování -aby se HLAVA žádost proti každé API endpoint, aby zajistily, že’reavailable.
možnosti
V neposlední řadě máme OPTIONS požadavky. Požadavky na možnosti jsoujeden z mých oblíbených, i když ne tak široce používaný jako ostatní HTTPmethods. Stručně řečeno, požadavek OPTIONS by měl vrátit datapopisovat, jaké další metody a operace server podporuje na dané adrese URL.
Požadavky na volby jsou volněji definovány a používány než ostatní, což z nich dělá dobrého kandidáta na testování fatálních chyb API. Pokud anAPI neočekává požadavek na možnosti, je dobré umístit testovací kasein, který ověří chování při selhání.
testování API s požadavky na volby
testování OPTIONS požadavek závisí na webové službě; ať už to nepodporuje a co se má vrátit, určí, jak byste to měli vyzkoušet.
Jak k ověření koncového bodu pomocí MOŽNOSTI:
- Především, podívejte se na reakci záhlaví a stavový kód žádosti
- Test koncové body, které nemají MOŽNOSTI podpory, a zajistit, že failappropriately
Další zdroje
to, Co jsem uvedeno výše, je jen výchozím bodem pro kopání v toHTTP metod a testování různých zdrojů API. Předpokládá se také většinou ideální případ-v reálném světě nejsou API tak strukturovaná jako příklady výše. To dělá testování různých metod proti APIan efektivní způsob, jak najít neočekávané chyby.