7 HTTP módszerek minden webfejlesztőnek tudnia kell, és hogyan kell tesztelni őket

Elgondolkozott már azon, hogy mi a különbség a GETés a POSTkérések között, vagy mikor kell használni a PUT? Nem vagy egyedül. A különböző HTTP módszerek vagy igék alapvető megértésével az API-k támogatása hasznos tudás az API-k feltárása és tesztelése során.

ebben a bejegyzésben megvitatom, hogyan használják az egyes HTTP módszereket, és hogyan kell őket beépíteni az API tesztelésbe.

HTTP módszerek

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

get

GET kérések a leggyakoribb és széles körben használt módszerek API-k ésweboldalak. Egyszerűen fogalmazva, a GET metódus az aserver adatainak visszavonására szolgál a megadott erőforráson. Tegyük fel például, hogy van egy APIwith a /users végpont. GET kérés készítése az adott végponthozvisszaadja az összes elérhető felhasználó listáját.

mivel a GET kérés csak adatokat kér, és nem módosítja az erőforrásokat, biztonságos és idempotens módszer.

API tesztelése GET kérésekkel

amikor API teszteket hoz létre ,aGET metódus valószínűleg a szolgáltatás fogyasztóinak leggyakoribb kéréstípusa lesz, ezért fontos, hogy minden ismert végpontot ellenőrizzen egy GET kéréssel.

alapszinten ezeket a dolgokat érvényesíteni kell:

• ellenőrizze, hogy egy érvényes GET kérés visszaadja-e a 200 állapotkódot.
• győződjön meg arról, hogy egy GET kérés egy adott erőforráshoz a correctdata értéket adja vissza. Például a GET /users a felhasználók listáját adja vissza.

GET gyakran az alapértelmezett módszer a HTTP kliensekben, így tesztek létrehozásaezeknek az erőforrásoknak egyszerűnek kell lenniük bármely választott eszközzel.

POST

a webszolgáltatásokban POST a kéréseket arra használják, hogy adatokat küldjenek az Apiservernek egy erőforrás létrehozásához vagy udpate-jéhez. A kiszolgálóra küldött adatokat a HTTP kérés lekérdező törzsében tárolják.

a legegyszerűbb példa egy kapcsolatfelvételi űrlap egy weboldalon. Amikor kitölti a bemeneteket egy űrlapon, és nyomja meg a Küldés gombot, az adatok a kérés választestébe kerülnek, és elküldik a szervernek. Ez talán JSON, XML vagy lekérdezési paraméterek (rengeteg más formátum van,de ezek a leggyakoribbak).

érdemes megjegyezni, hogy aPOST kérés nem idempotens. Itmutat adatokat a backend szerver (létrehozásával vagy frissítésével aresource), szemben a GET kérés, amely nem változtatja anydata. Itt van egy nagyszerű magyarázat az idempotenciára.

API tesztelése POST kérésekkel

a második leggyakoribb HTTP módszer, amellyel az API tesztjeiben találkozhat POST. Mint már említettük, POST a kéréseket arra használjuk, hogy adatokat küldjünk az API-kiszolgálónak, és létrehozzunk vagy frissítsünk egy erőforrást. Mivel a POST kérések módosítják az adatokat, fontos, hogy API tesztek legyenek a POST módszerek mindegyikéhez.

íme néhány tipp a POST kérések teszteléséhez:

• hozzon létre egy erőforrást egyPOST kéréssel, és győződjön meg róla, hogy a200 állapotkód visszatér.
• ezután adjon meg egyGET kérést az erőforráshoz, és győződjön meg arról, hogy az adatok helyesen lettek mentve.
• olyan tesztek hozzáadása, amelyek biztosítják, hogy aPOST kérések hibás vagy rosszul formázott adatokkal sikertelenek legyenek.

néhány további ötletet a közös API testingscenarios,nézd meg ezt a bejegyzést.

PUT

Simlar POST, PUT a kéréseket arra használják, hogy adatokat küldjenek az API-nak toupdate vagy hozzon létre egy erőforrást. A különbség az, hogy a put kérések idempotensek. Thatis, ha ugyanazt a PUT kérést többször hívja, mindig ugyanazt az eredményt fogja eredményezni. Ezzel szemben a postai kérés ismételt felhívásamellékhatásai vannak annak, hogy ugyanazt az erőforrást többször hozzák létre.

általában, amikor egy PUT kérés létrehoz egy erőforrást, a kiszolgáló válaszol egy 201Created), és ha a kérés módosítja a meglévő erőforrást, a kiszolgáló egy 200OK) vagy 204NoContent).

API tesztelése PUT kérésekkel

API-k tesztelése PUT módszerek nagyon hasonlóak a POSTrequests teszteléséhez. De most, hogy tudjuk a különbséget a kettő között(idempotency), API teszteket hozhatunk létre ennek a viselkedésnek a megerősítésére.

ellenőrizze ezeket a dolgokat a PUT kérések tesztelésekor:

• ismételten hívja a PUT kérés mindig ugyanazt az eredményt adja vissza(idempotent).
• az erőforrás létrehozásakor és frissítésekor a rendszer a megfelelő állapotkódot adja vissza (pl.201 vagy200204).
• miután frissítette az erőforrást egy PUTkéréssel, egyGET kéréshogy az erőforrásnak vissza kell adnia a helyes adatokat.
• PUT a kéréseknek sikertelennek kell lenniük, ha érvénytelen adatokat szolgáltatnak a thequest-ben-semmit sem kell frissíteni.

PATCH

a PATCH a kérés az egyik kevésbé ismert HTTP módszer, de én is ilyen magas a listán, mivel hasonló a POST andPUT-hoz. A PATCH különbség az, hogy csak a partialmodifications-t alkalmazza az erőforrásra.

a különbség a PATCH és a PUT között az, hogy a patch request nem idempotens (mint a POST request).

a részleges módosításhoz tegyük fel, hogy az API-nak van egy/users/{{userid}} végpontja, és a felhasználónak van egy felhasználóneve. Az aPATCH request használatával előfordulhat, hogy csak a frissített felhasználónevet kell elküldenie a kérelem törzsében – a POST and PUT helyett, amelyhez a fulluser entitás szükséges.

API tesztelése PATCH kérésekkel

mivel a PATCH módszer annyira egyszerű, hogy POST and PUT, sok azonos tesztelési technikát alkalmaznak. Még mindig fontos, hogy érvényesítsükaz API-végpontok viselkedését, amelyek elfogadják ezt a módszert.

mit kell keresni a PATCH kérések tesztelésekor:

• sikeres PATCH a kérésnek vissza kell adnia egy 2xx állapotkódot.
• PATCH a kéréseknek sikertelennek kell lenniük, ha érvénytelen adatokat szolgáltatnak a thequest-ben-semmit sem kell frissíteni.

a PATCH kérések szemantikája nagymértékben függ a tesztelt API-tól.

DELETE

a DELETE módszer pontosan olyan, amilyennek hangzik: törölje az erőforrást aa megadott URL-t. Ez a módszer az egyik leggyakoribb a RESTfulAPIs-ban, ezért jó tudni, hogyan működik.

API tesztelése törlési kérésekkel

DELETE a kéréseket erősen tesztelni kell, mivel általában eltávolítják az adatokat egy adatbázisból. Legyen óvatos a törlési módszerek tesztelésekor, győződjön meg róla, hogy a megfelelő hitelesítő adatokat használja, és nem teszteli a realuser adatokat.

a törlési kérelem tipikus tesztesete így néz ki:

1. Új felhasználó létrehozásaPOST kérés/users
2. aPOST, hogy egyDELETEkérés/users/{{userid}}
3. egy későbbiGETkérés/users/{{userid}} vissza kell adnia egy 404 Nem található állapotkódot.

Ezen kívül küld egy törlési kérelmet egy ismeretlen erőforrás shouldreturna non-200 állapotkódot.

HEAD

aHEAD módszer majdnem megegyezik aGET módszerrel, kivéve a választestet. Más szóval, ha a GET /users visszaadja a felhasználók listáját, akkor a HEAD /users ugyanazt a kérést fogja tenni, de nem kapja vissza a felhasználók listáját.

a FEJKÉRELMEK hasznosak annak ellenőrzéséhez, hogy a GET kérés visszatér-e, mielőtt ténylegesen megkapná a GET kérést-például egy nagy fájl vagy responsebody letöltése előtt. Tudjon meg többet az MDN FEJKÉRELMEIRŐL.

érdemes rámutatni, hogy nem minden olyan végpont, amely támogatja a GETWILL – t, támogatja a HEAD-t-ez teljesen a tesztelt API-tól függ.

API tesztelése HEAD kérésekkel

API kérések készítése HEAD módszerek valójában hatékony módja annak, hogy egyszerűen ellenőrizze, hogy rendelkezésre áll-e erőforrás. Ez goodpractice, hogy egy teszt fej kérések mindenhol van egy testfor get kérések (mindaddig, amíg az API támogatja azt).

ellenőrizze ezeket a dolgokat, amikor egy API-t tesztel HEAD kérésekkel:

• ellenőrizze andcheckHTTP fejlécek returnedfrom egy HEAD kérésből
• állítson be a head kérések állapotkódjával szemben
• tesztelje a kéréseket különböző lekérdezési paraméterekkelr az APIresponds biztosítása érdekében

egy másik hasznos eset aHEAD requestsisAPI smoke testing-készítsen HEAD kérést minden API végpont ellen annak biztosítása érdekében, hogy a fejlécek elérhető.

opciók

végül, de nem utolsósorban van OPTIONS kérések. Az opciók kéréseiaz egyik kedvencem, bár nem olyan széles körben használják, mint a többi HTTPmethods. Dióhéjban egy opciós kérelemnek vissza kell adnia az adatokat, leírva, hogy a kiszolgáló milyen egyéb módszereket és műveleteket támogat az adott URL-ben.

az opciós kéréseket lazábban definiálják és használják,mint a többieket, így jó jelölt a végzetes API hibák tesztelésére. Ha az anAPI nem számít OPCIÓKÉRÉSRE, akkor jó, ha egy teszt kazeint helyez el, amely ellenőrzi a hibás viselkedést.

API tesztelése opciós kérésekkel

OPTIONS kérés a webszolgáltatástól függ; függetlenül attól, hogy támogatja-e ezt, és mit kell visszatérnie, meghatározza, hogyan kell tesztelni.

hogyan lehet érvényesíteni egy végpontot az opciók használatával:

• elsősorban ellenőrizze a válasz fejlécét és a kérelem állapotkódját
• tesztelje azokat a végpontokat, amelyek nem támogatják az opciókat, és győződjön meg róla, hogy nem megfelelőek

további források

amit fentebb tárgyaltam, csak egy kiindulási pont a toHTTP módszerek ásásához és az API különböző erőforrásainak teszteléséhez. Azt is feltételezinagyrészt ideális eset – a való világban az API-k nem olyan strukturáltaka fenti példák. Ez teszi a különböző módszerek tesztelését az APIan ellen hatékony módja a váratlan hibák megtalálásának.