Vanliga API-fel och hur man åtgärdar dem

När du bygger vilken mjukvara som helst, oavsett om det är en webbplats eller applikation, är det ett måste att inkludera kvalitetssäkring i din mjukvaruutvecklingscykel. Om det missas finns det stora chanser att släppa buggy-instanser som säkerligen kommer att förstöra upplevelsen för slutanvändaren.

Ingen intressent skulle någonsin vilja att detta skulle hända. Det är därför testning är på sin vakt för framgångsrika utgåvor och säkerställer ett positivt svar på de funktioner du lägger till. Detta innebär de vanligaste användningsfallsscenarierna för att verifiera att flödena fungerar som förväntat innan någon av dina riktiga kunder har möjlighet att kontrollera det.

När du överväger vilka tester som ska inkluderas i din täckningssvit, var uppmärksam på API-testning, eftersom det är en av de viktigaste och mest använda typerna. API:er (Application Programming Interfaces) finns i alla applikationer och ansvarar för korrekt kommunikation mellan flera programvarusystem. Huvudfunktionerna för API:er inkluderar att specificera de dataförfrågningar som kan överföras och villkoren för att dessa förfrågningar ska behandlas. 

En användare vill till exempel lägga till något föremål i en kundvagn, trycker på en motsvarande knapp som utlöser en API-begäran, tar emot svaret och varukorgen uppdateras. Om denna begäran misslyckas kommer "lägg till i kundvagn"-funktionen att gå sönder.

Det är så problem med API kan påverka verksamheten, vilket lägger till en viktig faktor till varför alla borde testa det ordentligt. För att införliva denna testning bör man börja med de rätta automations- API-testverktygen för att se till att inget fel slinker igenom.

Det kan finnas olika API-fel, och här kommer vi att berätta mer om de fem mest populära: 

Felaktig HTTP-metod

Det enklaste men ändå utbredda API-felet är den felaktiga HTTP-metoden. Ofta orsakas problemet av luckor i dokumentationen. Ett av exemplen kan vara att skicka en GET-begäran som specificerar dataalternativet, men hoppa över att nämna -X GET-parametern. Som ett resultat konverteras den automatiskt till en POST-begäran. Problemen med HTTP-metoder kan också uppstå när du byter API-verktyg eftersom vissa av dem kan använda en metod för att skapa testmiljöer och modifiera dem, medan andra använder separata sätt för dessa åtgärder. Det är därför det är viktigt att noggrant kontrollera dessa nyanser, samt anta ett konsekvent tillvägagångssätt för att skriva din egen dokumentation. 

Använder fel protokoll

Ett annat vanligt fel är avvikelserna mellan https://- och http://-protokollen. Vissa API:er kanske bara stöder ett av protokollen, låt oss säga http, så att ange https:// i ett sådant fall kommer att leda till felaktig behandling av begäran. Även om båda stöds kan det finnas problem med omdirigeringen till https:// när du anger http://. Fallet kan också uppstå när leverantörer av tredje parts API:er som du planerar att använda gör vissa ändringar och misslyckas med att skicka ett meddelande om det. Så det är bättre att ompröva dessa aspekter då och då. För att skapa ditt eget API är det bättre att använda https://-protokollet. För att göra det möjligt krävs det att du installerar ett SSL-certifikattill värden. För en tid sedan var SSL-certifikat lite kostsamma så det kan finnas tvivel angående det, men med gratisleverantörer som Letsencrypt eller Cloudflare blir det enklare än någonsin.

Avsaknad av meningsfulla felmeddelanden

Om du någonsin har stött på ett " oväntat API-fel”, du vet hur irriterande den här kan vara. Vanligtvis är felmeddelanden tänkta att underlätta felsökning för utvecklarna som pekar ut den exakta orsaken till felet eller åtminstone var de ska söka efter det. Tyvärr kan sådana oinformativa fel resultera i timmar av bortkastad tid, öka den tid som krävs för att lösa felet och följaktligen orsaka en större ökning av den negativa feedback du får, det är därför det är bättre att lägga lite mer tid på att beskriva potentialen fel och göra meddelandena informativa för dem som kommer att behöva felsöka dem. Även om det finns flera dussintals HTTP-felkoder, är det inte nödvändigt att använda alla, men behåll standardfelkoderna (200,400 och 500) och överväg att inkludera tipsen i meddelandena så att även i fall när något inte fungerar,

Auktoriseringsproblem

Det kan tyckas att allt är klart här eftersom felaktig auktorisering vanligtvis förutsätter att användarnamnet eller lösenordet är felaktigt, men faktiskt, även att blanda ihop "auktorisering" med "autentisering" i rubriker orsakar felet. Det är särskilt giltigt när du använder OAuth 2-protokollet. Syntaxen spelar också roll, eftersom vissa enkla men mindre uppenbara saker kan skapa förvirring. I de flesta fall är dessa bärartoken, utrymmet i prefixet "Basic", som saknas för att lägga till detta prefix helt och förlorar kolon i paret "användarnamn: lösenord". Även när användarnamnet används ensamt i vissa API:er som inte kräver lösenordet, kommer du fortfarande att behöva använda detta kolon.

Det gick inte att ange rubrikerna Content-Type och Accept

Vissa API:er är toleranta mot förfrågningar där rubriker inte innehåller Content-Type eller Accept-huvudet utan motsvarar det tillåtna dataformatet. Andra är mer noggranna och kommer inte att låta begäran gå igenom felkoden 403 Permission Denied. I detta skede etableras interaktionen mellan klienten och servern angående den förväntade datatypen i begäran och svaret. Denna rubrikkontroll är implementerad för att minska riskerna för säkerhetsintrång och övergripande hackningsförsök, det är därför det är bättre att specificera dessa rubriker för att undvika problem under användning.

Sammanfatta

Genom att utföra API-testning tillsammans med de andra testtyperna inklusive regression, röktest och naturligtvis enhetstestning under utvecklingssprintarna kommer din mjukvarusläpp att ske snabbare. Logiken bakom det är enkel: ju tidigare en bugg, defekt eller inkonsekvens med affärskraven upptäcks, desto lättare är det att fixa det. Och, som ett resultat, leverera den förstklassiga upplevelsen till dina slutanvändare som kommer att kunna njuta av interaktionen med din programvara utan några oväntade buggar i processen, vilket ger mer vinst till ditt företag.