Vanlige API-feil og hvordan du fikser dem

Når du bygger et stykke programvare, enten det er et nettsted eller en applikasjon, er det et must å inkludere kvalitetssikring i programvareutviklingssyklusen. Hvis det går glipp av det, er det store sjanser for å gi ut buggy-forekomster som helt sikkert vil ødelegge opplevelsen til sluttbrukeren.

Ingen interessenter vil noensinne at dette skal skje. Det er derfor testing er på vakt for vellykkede utgivelser og sikrer en positiv respons på funksjonene du legger til. Dette innebærer de vanligste bruksscenarioene for å verifisere at flytene fungerer som forventet før noen av dine virkelige kunder har mulighet til å sjekke det.

Når du vurderer hvilke tester som skal inkluderes i dekningspakken din, vær oppmerksom på API-testing, siden det er en av de viktigste og mest brukte typene. APIer (Application Programming Interfaces) er tilstede i enhver applikasjon og er ansvarlig for riktig kommunikasjon mellom flere programvaresystemer. Hovedfunksjonene til APIer inkluderer å spesifisere dataforespørslene som kan overføres og betingelsene for at disse forespørslene skal behandles. 

En bruker ønsker for eksempel å legge til en vare i en handlekurv, trykker på en tilsvarende knapp som utløser en API-forespørsel, mottar svaret og handlekurven oppdateres. Hvis denne forespørselen mislykkes, vil "legg i handlekurv"-funksjonen brytes.

Det er slik problemer med API kan påvirke virksomheten, og legger til en viktig faktor til hvorfor alle bør teste det ordentlig. For å inkludere denne testingen, bør man starte med de riktige automatiserings -API-testverktøyene for å sikre at ingen feil slipper gjennom.

Det kan være forskjellige API-feil, og her vil vi fortelle deg mer om 5 av de mest populære: 

Feil HTTP-metode

Den enkleste, men utbredte API-feilen er feil HTTP-metoden. Ofte er problemet forårsaket av hull i dokumentasjonen. Et av eksemplene kan være å sende en GET-forespørsel som spesifiserer dataalternativet, men hopp over å nevne -X GET-parameter. Som et resultat blir den automatisk konvertert til en POST-forespørsel. Problemer med HTTP-metoder kan også oppstå når du bytter API-verktøy fordi noen av dem kan bruke én metode for å lage testmiljøer og endre dem, mens andre bruker separate måter for disse handlingene. Derfor er det viktig å nøye sjekke disse nyansene, i tillegg til å bruke en konsekvent tilnærming til å skrive din egen dokumentasjon. 

Bruker feil protokoll

En annen vanlig feil er avvikene mellom https://- og http://-protokollene. Noen API-er støtter kanskje bare én av protokollene, la oss si http, så å spesifisere https:// i slike tilfeller vil føre til feil behandling av forespørselen. Selv om begge støttes, kan det være problemer med omdirigeringen til https:// når du angir http://. Saken kan også oppstå når leverandører av tredjeparts API-er du planlegger å bruke gjør noen endringer og ikke sender et varsel om det. Så det er bedre å sjekke disse aspektene på nytt fra tid til annen. For å lage din egen API, er det bedre å bruke https://-protokollen. For å gjøre det mulig, er det nødvendig å installere et SSL-sertifikattil verten. For en tid siden var SSL-sertifikater litt kostbare, så det kan være tvil om det, men med gratisleverandører som Letsencrypt eller Cloudflare blir det enklere enn noen gang.

Fravær av meningsfulle feilmeldinger

Hvis du noen gang har møtt en " uventet API-feil", du vet hvor irriterende denne kan være. Vanligvis er det meningen at feilmeldinger skal lette feilsøking for utviklerne som påpeker den nøyaktige årsaken til feilen eller i det minste hvor de skal søke etter den. Dessverre kan slike uinformative feil resultere i timer med bortkastet tid, øke tiden som kreves for å løse feilen, og følgelig forårsake en større økning i de negative tilbakemeldingene du mottar, det er derfor det er bedre å bruke litt mer tid på å beskrive potensialet feil og gjøre meldingene informative for de som trenger å feilsøke dem. Selv om det finnes flere titalls HTTP-feilkoder, er det ikke nødvendig å bruke dem alle, men behold standard feilkoder (200,400 og 500) og vurder å inkludere hintene i meldingene slik at selv i tilfeller der noe ikke fungerer,

Autorisasjonsproblemer

Det kan virke som at alt her er klart, da feil autorisasjon vanligvis forutsetter at brukernavnet eller passordet er feil, men faktisk forårsaker feilen selv å forveksle "autorisasjon" med "autentisering" i overskrifter. Det er spesielt gyldig ved bruk av OAuth 2-protokollen. Syntaksen er også viktig, fordi noen enkle, men mindre åpenbare ting kan skape forvirring. I de fleste tilfeller er dette bærersymbolet, plassen i «Basic»-prefikset, mangler for å legge til dette prefikset fullstendig, og tap av kolon i «brukernavn: passord»-paret. Selv når brukernavnet brukes alene i enkelte APIer som ikke krever passordet, må du fortsatt bruke dette kolon.

Klarer ikke å spesifisere Content-Type og Accept-overskriftene

Noen API-er er tolerante for forespørslene der overskrifter ikke inneholder Content-Type eller Accept-overskriften, men samsvarer med det tillatte dataformatet. Andre er mer nøye og lar ikke forespørselen gi ut feilkoden 403 Permission Denied. På dette stadiet etableres interaksjonen mellom klienten og serveren angående forventet datatype i forespørselen og svaret. Denne overskriftskontrollen er implementert for å redusere risikoen for sikkerhetsbrudd og generelle hackingforsøk, det er derfor det er bedre å spesifisere disse overskriftene for å unngå problemer under bruk.

Avslutning

Å utføre API-testing sammen med de andre testtypene, inkludert regresjon, røyktest og selvfølgelig enhetstesting under utviklingssprintene, vil hjelpe programvareutgivelsen til å skje raskere. Logikken bak det er enkel: Jo før en feil, defekt eller inkonsistens med forretningskravene blir lagt merke til, jo lettere er det å fikse det. Og, som et resultat, leverer den førsteklasses opplevelsen til sluttbrukerne dine som vil kunne nyte interaksjonen med programvaren din uten uventede feil i prosessen, og dermed gi mer fortjeneste til virksomheten din.