7 HTTP-menetelmiä jokaisen web-kehittäjän tulisi tietää ja miten ne testataan

Oletko koskaan miettinyt, mikä ero on GET ja POSTpyynnöt, tai milloin käyttää PUT? Et ole yksin. Sovellusliittymä on hyödyllinen tieto sovellusliittymien tutkimisessa ja testaamisessa, koska se ymmärtää eri HTTP-menetelmiä tai verbejä.

tässä viestissä pohdin, miten kutakin HTTP-menetelmää käytetään ja miten ne sisällytetään API-testaukseen.

HTTP Methods

• GET

POSTPUTHEADDELETEPATCHOPTIONS

get

GET pyynnöt ovat yleisimpiä ja laajimmin käytettyjä menetelmiä sovellusliittymissä ja WWW-sivustoissa. Yksinkertaisesti sanottuna GET-menetelmää käytetään tietojen palauttamiseen aserverilta määritetyssä resurssissa. Esimerkiksi sanotaan, että sinulla on APIwith a /users päätepiste. GET-pyynnön tekeminen kyseiseen päätepisteeseen olisi laadittava luettelo kaikista käytettävissä olevista käyttäjistä.

koska GET-pyyntö pyytää vain tietoja eikä muuta mitään resursseja, se on katsottu turvalliseksi ja idempotentiksi menetelmäksi.

API: n testaaminen GET-pyynnöillä

kun luodaan testejä API: lle, GET menetelmä on todennäköisesti yleisin palvelun kuluttajien tekemä pyyntö, joten on tärkeää tarkistaa jokainen tunnettu päätepiste GET-pyynnöllä.

perustasolla nämä asiat pitäisi validoida:

• Tarkista, että kelvollinen GET-pyyntö palauttaa 200 tilakoodi.
• varmista, että GET-pyyntö tietylle resurssille palauttaa oikean tiedon. Esimerkiksi GET /users palauttaa listan käyttäjistä.

GET on usein HTTP-asiakkaiden oletustapa, joten näiden resurssien testaamisen tulisi olla yksinkertaista millä tahansa työkalulla.

POST

verkkopalveluissa POST pyyntöjä käytetään datan lähettämiseen sovelluspalvelimelle resurssin luomiseksi tai udpatoimiseksi. Palvelimelle lähetetyt tiedot on tallennettu HTTP-pyynnön pyyntöön.

yksinkertaisin esimerkki on yhteydenottolomake verkkosivulla. Kun täytät syötteet lomakkeessa ja painat Lähetä-painiketta, tiedot asetetaan pyynnön vastauselimeen ja lähetetään palvelimelle. Tämä ehkä JSON, XML, tai kyselyn parametrit (on paljon muita formaatteja,mutta nämä ovat yleisimpiä).

on syytä huomata, että POST pyyntö on ei-idempotentti. Itmutates data on the backend server (by creating or updating aresource), toisin kuin a GET request which does not change anydata. Tässä on suuri selitys idempotenttisuus.

API: n testaaminen POST-pyynnöillä

toiseksi yleisin HTTP-menetelmä, johon törmäät API-testeissäsi POST. Kuten edellä mainittiin, POST pyyntöjä käytetään lähettämään tietoja API-palvelimelle ja luomaan tai päivittämään resurssi. Koska post-pyynnöt muokkaavat tietoja, on tärkeää saada API-testit allof POST-menetelmillesi.

Tässä muutamia vinkkejä POSTIPYYNTÖJEN testaamiseen:

• Luo Resurssi, jolla on POST pyyntö ja varmista, että 200 tilakoodi palautetaan.
• tee seuraavaksi GET pyyntö kyseiselle resurssille ja varmista, että tiedot on tallennettu oikein.
• lisää testit, jotka varmistavat POST pyynnöt epäonnistuvat virheellisillä tai huonosti muotoilluilla tiedoilla.

Jos haluat lisää ideoita yhteisistä API testingscenarioista,Katso tästä postauksesta.

PUT

Simlar to POST, PUT pyyntöjä käytetään datan lähettämiseen API-tupdaattiin tai resurssin luomiseen. Erona on, että lähettämispyynnöt ovat idempotentteja. Thatis, soittamalla sama laittaa pyynnön useita kertoja tuottaa aina saman tuloksen. Sen sijaan soittamalla POST pyyntö toistuvasti makehave sivuvaikutuksia luoda saman resurssin useita kertoja.

yleensä, kun PUT pyyntö luo resurssin, palvelin vastaa 201Created), ja jos pyyntö muuttaa olemassa olevaa resurssia, palvelin palauttaa 200OK) tai 204NoContent).

API: n testaus PUT-pyynnöillä

API: n testaus PUT menetelmät ovat hyvin samankaltaisia kuin Jälkitestit. Mutta nyt kun tiedämme eron näiden kahden(idempotency) välillä, voimme luoda API-testejä tämän käyttäytymisen vahvistamiseksi.

tarkista nämä asiat testattaessa PUT-pyyntöjä:

• toistuvasti soittamalla PUT pyyntö palauttaa aina saman tuloksen(idempotentti).
• oikea tilakoodi palautetaan resurssia luotaessa ja päivitettäessä (esim. 201 tai 200204).
• päivitettyään resurssin, jolla on PUT pyyntö, GET pyyntö resurssin pitäisi palauttaa oikeat tiedot.
• PUT pyynnöt hylätään, jos pyyntöön on toimitettu virheellisiä tietoja — mitään ei pidä päivittää.

PATCH

a PATCH request on yksi vähemmän tunnetuista HTTP-menetelmistä, mutta I ’ mincluding it this high in the list for it is similar to POST andPUT. Erona PATCH on, että resurssiin sovelletaan vain osittaisia muunnoksia.

PATCH-ja PUT-pyyntöjen erona on, että patch-pyyntö ei ole idempotentti (likea POST-pyyntö).

Jos haluat laajentaa osittaista muokkausta, sano, että olet API: lla on

päätepiste, ja käyttäjällä on käyttäjätunnus. Apatch request, sinun tarvitsee vain lähettää päivitetty käyttäjätunnus in request body-toisin kuin POST ja PUT, jotka vaativat fulluser entity.

API: n testaus PAIKKAPYYNNÖILLÄ

koska PATCH menetelmä on niin simlar lähettää ja laittaa, monet näistä samoista testaustekniikoista pätevät. On edelleen tärkeää vahvistaa tämän menetelmän hyväksyvien API-päätepisteiden toimivuus.

mitä etsiä testattaessa LAASTARIPYYNTÖJÄ:

• onnistuneen PATCH pyynnön pitäisi palauttaa 2xx tilakoodi.
• PATCH pyynnöt hylätään, jos pyyntöön on toimitettu virheellisiä tietoja — mitään ei pidä päivittää.

PAIKKAPYYNTÖJEN semantiikka riippuu pitkälti testaamastasi API: sta.

poista

DELETE menetelmä on juuri sellainen kuin miltä se kuulostaa: poista resurssi määritetystä URL-osoitteesta. Tämä menetelmä on yksi yleisempiä RESTfulAPIs joten on hyvä tietää, miten se toimii.

API: n testaus POISTOPYYNNÖILLÄ

DELETE pyynnöt tulisi testata raskaasti, koska ne yleensä poistetaan tietokannasta. Ole varovainen, kun testaat poista-menetelmiä, varmista, että käytät oikeita tunnistetietoja etkä testaa realuser-tiedoilla.

tyypillinen poistopyynnön testitapaus näyttäisi tältä:

1. Luo uusi käyttäjä POST pyyntö /users
2. käyttäjätunnuksen ollessa palautettuna POST, tee DELETE pyyntö /users/{{userid}}
3. myöhemmin GET pyyntö /users/{{userid}} pitäisi palauttaa 404 Not Found-tilakoodi.

lisäksi lähetetään poistopyyntö tuntemattomalle resurssille shouldreturna non-200-tilakoodi.

HEAD

HEAD menetelmä on lähes identtinen GET, paitsi ilman theresponse-runkoa. Toisin sanoen, jos GET /users palauttaa listan käyttäjistä, niin HEAD /users tekee saman pyynnön, mutta ei saa takaisin luetteloa käyttäjistä.

HEAD-pyynnöt ovat hyödyllisiä tarkistettaessa, mitä GET-pyyntö kääntyy ennen GET-pyynnön tekemistä-kuten ennen suuren tiedoston tai vastauskehon lataamista. Lue lisää pään pyynnöistä MDN: ssä.

on syytä huomauttaa, että jokainen getwilliä tukeva päätepiste ei tue päätä – se riippuu täysin TESTAAMASTASI API: sta.

API: n testaaminen pään pyynnöillä

API-pyyntöjen tekeminen HEAD – menetelmillä on itse asiassa tehokas tapa yksinkertaisesti tarkistaa, että resurssi on käytettävissä. On hyvä käytäntö pitää testi pään pyyntöjä kaikkialla sinulla on testi saada pyyntöjä (kunhan API tukee sitä).

tarkista nämä asiat, kun testaat API: a pään pyynnöillä:

• Tarkista jacheckhttp://li>
• esittää väitteitä pään pyyntöjen tilakoodista
• Testipyynnöt erilaisilla kyselyparametreilla Apirespondien varmistamiseksi

toinen hyödyllinen tapaus HEAD requestsisAPI savutestaus-tee pään pyyntö jokaista API-päätetapahtumaa vastaan varmistaakseen, että ne olen käytettävissä.

vaihtoehdot

viimeisenä mutta ei vähäisimpänä meillä on OPTIONS pyynnöt. OPTIOPYYNNÖT ovat yksi suosikeistani, joskaan niitä ei käytetä yhtä laajasti kuin muita Httpmetodeja. Pähkinänkuoressa, OPTIOPYYNNÖN pitäisi palauttaa datadecribing mitä muita menetelmiä ja toimintoja palvelin tukee annettuun URL.

VALINTAPYYNNÖT on määritelty ja niitä käytetään muita löyhemmin,joten ne ovat hyvä ehdokas kohtalokkaiden API-virheiden testaamiseen. Jos anAPI ei odota OPTIOPYYNTÖÄ, on hyvä laittaa testikaseiinipaikka, joka todentaa epäonnistuneen käyttäytymisen.

API: n testaus OPTIOPYYNNÖILLÄ

testaus OPTIONS pyyntö riippuu verkkopalvelusta; onko se tukee sitä ja mitä pitäisi palata määrittelee, miten sinun pitäisi testata sitä.

miten validoida päätetapahtuma vaihtoehtojen avulla:

• tarkista ensisijaisesti pyynnön vasteotsikot ja tilakoodi
• testin päätepisteet, jotka eivät tue vaihtoehtoja, ja varmista, että ne epäonnistuvat asianmukaisesti

lisää resursseja

mitä olen edellä käsitellyt, on vain lähtökohta API: n menetelmien ja erilaisten resurssien tutkimiselle. Se olettaa myös, että kyseessä on useimmiten ideaalitapaus – reaalimaailmassa sovellusliittymät eivät ole yhtä rakenteellisia kuin yllä olevat esimerkit. Tämä tekee testaus eri menetelmiä vastaan APIan tehokas tapa löytää odottamattomia vikoja.