Yleiset API-virheet ja niiden korjaaminen

Kun rakennat mitä tahansa ohjelmistoa, oli se sitten verkkosivusto tai sovellus, laadunvarmistus on sisällytettävä ohjelmistokehitysjaksoosi. Jos se unohtuu, on suuri todennäköisyys julkaista bugisia esiintymiä, jotka varmasti pilaavat loppukäyttäjän kokemuksen.

Yksikään sidosryhmä ei koskaan haluaisi tämän tapahtuvan. Siksi testaus pysyy valppaana onnistuneiden julkaisujen suhteen ja varmistaa positiivisen vastauksen lisäämiisi ominaisuuksiin. Tämä sisältää yleisimmät käyttötapausskenaariot, joilla varmistetaan, että virrat toimivat odotetulla tavalla, ennen kuin kukaan todellisista asiakkaistasi voi tarkistaa sen.

Kun harkitset, mitä testejä sisällytät kattavuuspakettiisi, kiinnitä huomiota API-testaukseen, koska se on yksi tärkeimmistä ja laajimmin käytetyistä tyypeistä. API:t (sovellusohjelmointirajapinnat) ovat läsnä kaikissa sovelluksissa, ja ne ovat vastuussa useiden ohjelmistojärjestelmien välisestä asianmukaisesta tiedonsiirrosta. API:iden päätoimintoihin kuuluu siirrettävien tietopyyntöjen ja näiden pyyntöjen käsittelyehtojen määrittäminen. 

Esimerkiksi käyttäjä haluaa lisätä jonkin tuotteen ostoskoriin, painaa vastaavaa painiketta, joka käynnistää API-pyynnön, vastaanottaa vastauksen ja ostoskori päivitetään. Jos tämä pyyntö epäonnistuu, "Lisää ostoskoriin" -ominaisuus katkeaa.

Näin API-ongelmat voivat vaikuttaa liiketoimintaan, mikä lisää yhden tärkeän tekijän, miksi kaikkien pitäisi testata sitä kunnolla. Tämän testauksen sisällyttämiseksi sinun tulee aloittaa oikeilla automaation API-testaustyökaluilla varmistaaksesi, ettei virhe lipsu läpi.

API-virheitä voi olla erilaisia, ja tässä kerromme sinulle lisää viidestä suosituimmasta: 

Väärä HTTP-menetelmä

Yksinkertaisin, mutta laajalle levinnyt API-virhe on väärä HTTP-menetelmä. Usein ongelma johtuu puutteista dokumentaatiossa. Yksi esimerkeistä voi olla GET-pyynnön lähettäminen, joka määrittää datavaihtoehdon, mutta ohita -X GET-parametrin mainitseminen. Tämän seurauksena se muunnetaan automaattisesti POST-pyynnöksi. Myös HTTP-menetelmien ongelmia voi ilmetä API-työkaluja vaihdettaessa, koska jotkut niistä voivat käyttää yhtä menetelmää testiympäristöjen luomiseen ja muokkaamiseen, kun taas toiset käyttävät eri tapoja näihin toimintoihin. Siksi on tärkeää tarkistaa nämä vivahteet huolellisesti ja omaksua johdonmukainen lähestymistapa oman dokumentaation kirjoittamiseen. 

Väärän protokollan käyttö

Toinen yleinen virhe on https://- ja http://-protokollien väliset erot. Jotkut API:t voivat tukea vain yhtä protokollista, esimerkiksi http, joten https://:n määrittäminen tällaisessa tapauksessa johtaa virheelliseen pyynnön käsittelyyn. Vaikka molempia tuettaisiin, uudelleenohjauksessa https:// voi esiintyä ongelmia, kun määrität http://. Tapaus voi tapahtua myös silloin, kun käyttämiesi kolmannen osapuolen API-palveluntarjoajat tekevät joitain muutoksia eivätkä lähetä niistä ilmoitusta. Joten on parempi tarkistaa nämä näkökohdat uudelleen aika ajoin. Oman API:n luomiseen on parempi käyttää https://-protokollaa. Jotta se olisi mahdollista, sinun on asennettava SSL-varmenneisännälle. Jokin aika sitten SSL-varmenteet olivat hieman kalliita, joten niiden suhteen saattoi olla epäilyksiä, mutta ilmaisten palveluntarjoajien, kuten Letsencrypt tai Cloudflare, kanssa siitä tulee helpompaa kuin koskaan.

Merkittävien virheilmoitusten puuttuminen

Jos olet joskus kohdannut " odottamattoman API-virheen”, tiedät kuinka ärsyttävää tämä voi olla. Yleensä virheilmoitusten oletetaan helpottavan vianmääritystä kehittäjille, jotka osoittavat virheen tarkan syyn tai ainakin mistä etsiä sitä. Valitettavasti tällaiset epätietoiset virheet voivat johtaa tuntien hukkaan, pidentää virheen ratkaisemiseen tarvittavaa aikaa ja siten aiheuttaa suuremman piikkien saamassasi negatiivisessa palautteessa, minkä vuoksi on parempi käyttää hieman enemmän aikaa mahdollisen kuvaukseen. virheitä ja tehdä viesteistä informatiivisia niille, jotka tarvitsevat vianmäärityksen. Vaikka HTTP-virhekoodeja on useita kymmeniä, niitä ei tarvitse käyttää kaikkia, vaan säilytä vakiovirhekoodit (200 400 ja 500) ja harkitse vihjeiden sisällyttämistä viesteihin, jotta myös silloin, kun jokin ei toimi,

Valtuutuksen ongelma

Vaikuttaa siltä, ​​että tässä kaikki on selvää, sillä väärä valtuutus edellyttää yleensä, että käyttäjätunnus tai salasana on väärä, mutta itse asiassa jopa "valtuutuksen" sekoittaminen otsikoissa "todennus" aiheuttaa virheen. Se on erityisen pätevä käytettäessä OAuth 2 -protokollaa. Myös syntaksilla on väliä, koska jotkut yksinkertaiset mutta vähemmän ilmeiset asiat voivat aiheuttaa sekaannusta. Useimmissa tapauksissa nämä ovat siirtotietunnus, välilyönti "Perus"-etuliitteessä, puuttuu tämän etuliite lisäämisestä kokonaan ja kaksoispiste "käyttäjätunnus: salasana" -parissa. Vaikka käyttäjätunnusta käytetään yksinään joissakin sovellusliittymissä, jotka eivät vaadi salasanaa, sinun on silti käytettävä tätä kaksoispistettä.

Content-Type- ja Accept-otsikoiden määrittäminen epäonnistui

Jotkut API:t sietävät pyyntöjä, joissa otsikot eivät sisällä Content-Type- tai Accept-otsikkoa, mutta vastaavat sallittua tietomuotoa. Toiset ovat tarkempia eivätkä anna pyyntöä antaa 403 Permission Denied -virhekoodia. Tässä vaiheessa muodostetaan asiakkaan ja palvelimen välinen vuorovaikutus pyynnön ja vastauksen odotetun tietotyypin suhteen. Tämä otsikkotarkistus on toteutettu vähentämään tietoturvaloukkausten ja yleisten hakkerointiyritysten riskiä, ​​minkä vuoksi on parempi määrittää nämä otsikot käytön ongelmien välttämiseksi.

Paketoida

API-testauksen suorittaminen muiden testaustyyppien kanssa, mukaan lukien regressio, savutesti ja tietysti yksikkötestaus kehityssprinttien aikana, auttaa ohjelmiston julkaisua nopeammin. Sen taustalla oleva logiikka on yksinkertainen: mitä nopeammin bugi, vika tai epäjohdonmukaisuus liiketoiminnan vaatimusten kanssa havaitaan, sitä helpompi se on korjata. Tämän seurauksena tarjoat huippuluokan kokemuksen loppukäyttäjillesi, jotka voivat nauttia vuorovaikutuksesta ohjelmistosi kanssa ilman odottamattomia virheitä, mikä tuo enemmän voittoa yrityksellesi.