Almindelige API-fejl og hvordan man løser dem

Når du bygger et stykke software, hvad enten det er et websted eller en applikation, er det et must at inkludere kvalitetssikring i din softwareudviklingscyklus. Hvis det går glip af, er der store chancer for at frigive buggy-forekomster, der helt sikkert vil ødelægge oplevelsen for slutbrugeren.

Ingen interessenter ville nogensinde ønske, at dette skulle ske. Det er derfor, at test forbliver på vagt for vellykkede udgivelser og sikrer en positiv respons på de funktioner, du tilføjer. Dette indebærer de mest almindelige use case-scenarier for at verificere, at flowene fungerer som forventet, før nogen af ​​dine rigtige kunder har mulighed for at kontrollere det.

Når du overvejer, hvilke test der skal inkluderes i din dækningspakke, skal du være opmærksom på API-testning, da det er en af ​​de vigtigste og mest brugte typer. API'er (Application Programming Interfaces) er til stede i enhver applikation og er ansvarlig for den korrekte kommunikation mellem flere softwaresystemer. Hovedfunktionerne i API'er inkluderer at specificere de dataanmodninger, der kan transmitteres, og betingelserne for, at disse anmodninger behandles. 

For eksempel ønsker en bruger at tilføje en vare til en kurv, trykker på en tilsvarende knap, der udløser en API-anmodning, modtager svaret, og kurven opdateres. Hvis denne anmodning mislykkes, vil "tilføj til kurv"-funktionen bryde.

Det er sådan problemer med API kan påvirke forretningen og tilføjer endnu en vigtig faktor, hvorfor alle bør teste det ordentligt. For at inkorporere denne test, bør man starte med de rigtige automatiserings -API-testværktøjer for at sikre, at ingen fejl slipper igennem.

Der kan være forskellige API-fejl, og her vil vi fortælle dig mere om 5 de mest populære: 

Forkert HTTP-metode

Den enkleste, men udbredte API-fejl er den forkerte HTTP-metode. Ofte er problemet forårsaget af huller i dokumentationen. Et af eksemplerne kan være at sende en GET-anmodning, der specificerer dataindstillingen, men spring over at nævne -X GET-parameteren. Som et resultat bliver det automatisk konverteret til en POST-anmodning. Problemerne med HTTP-metoder kan også opstå, når der skiftes API-værktøjer, fordi nogle af dem kan bruge én metode til at oprette testmiljøer og ændre dem, mens andre bruger separate måder til disse handlinger. Derfor er det vigtigt at kontrollere disse nuancer omhyggeligt og anvende en konsekvent tilgang til at skrive din egen dokumentation. 

Bruger den forkerte protokol

En anden almindelig fejl er uoverensstemmelserne mellem https://- og http://-protokollerne. Nogle API'er understøtter muligvis kun én af protokollerne, lad os sige http, så angivelse af https:// i sådanne tilfælde vil føre til forkert behandling af anmodninger. Selvom begge er understøttet, kan der være problemer med omdirigeringen til https://, når du angiver http://. Tilfældet kan også forekomme, når udbydere af tredjeparts-API'er, du planlægger at bruge, foretager nogle ændringer og undlader at sende en meddelelse om det. Så det er bedre at tjekke disse aspekter igen fra tid til anden. For at oprette din egen API er det bedre at bruge https://-protokollen. For at gøre det muligt, er det nødvendigt at installere et SSL-certifikattil værten. For noget tid siden var SSL-certifikater lidt dyre, så der kunne være tvivl om det, men med gratis udbydere som Letsencrypt eller Cloudflare bliver det nemmere end nogensinde.

Fravær af meningsfulde fejlmeddelelser

Hvis du nogensinde har stået over for en " uventet API-fejl”, ved du hvor irriterende denne her kan være. Normalt formodes fejlmeddelelser at lette fejlfinding for udviklerne, der påpeger den nøjagtige årsag til fejlen eller i det mindste hvor de skal søge efter den. Desværre kan sådanne uinformative fejl resultere i timers spildtid, øge den tid, der kræves for at løse fejlen, og som følge heraf forårsage en større stigning i den negative feedback, du modtager, derfor er det bedre at bruge lidt mere tid på at beskrive potentialet. fejl og gør meddelelserne informative for dem, der skal fejlfinde dem. Selvom der findes adskillige snesevis af HTTP-fejlkoder, er det ikke nødvendigt at bruge dem alle, men behold standardfejlkoderne (200,400 og 500), og overvej at inkludere hints i meddelelserne, så selv i tilfælde, hvor noget ikke fungerer,

Autorisationsproblemer

Det kan se ud til, at alt er klart her, da forkert autorisation normalt forudsætter, at brugernavnet eller adgangskoden er forkert, men faktisk forårsager selv forveksling af "autorisation" med "godkendelse" i overskrifter fejlen. Det er især gyldigt ved brug af OAuth 2-protokollen. Syntaksen har også betydning, fordi nogle simple, men mindre indlysende ting kan skabe forvirring. I de fleste tilfælde er disse bærer-tokenet, mellemrummet i "Basic"-præfikset, der mangler for at tilføje dette præfiks fuldstændigt, og tab af kolon i "brugernavn: adgangskode"-parret. Selv når brugernavnet bruges alene i nogle API'er, der ikke kræver adgangskoden, skal du stadig bruge dette kolon.

Kunne ikke angive overskrifterne Content-Type og Accept

Nogle API'er er tolerante over for anmodninger, hvor headere ikke indeholder Content-Type eller Accept-headeren, men svarer til det tilladte dataformat. Andre er mere omhyggelige og vil ikke lade anmodningen udlevere fejlkoden 403 Permission Denied. På dette stadium etableres interaktionen mellem klienten og serveren vedrørende den forventede datatype i anmodningen og svaret. Dette header-tjek er implementeret for at mindske risikoen for sikkerhedsbrud og overordnede hackingforsøg, derfor er det bedre at specificere disse headere for at undgå problemer under brug.

Afslutning

Udførelse af API-test sammen med de andre testtyper inklusive regression, røgtest og selvfølgelig enhedstest under udviklingssprintene vil hjælpe din softwarefrigivelse til at ske hurtigere. Logikken bag det er enkel: Jo hurtigere en fejl, defekt eller uoverensstemmelse med forretningskravene opdages, jo lettere er det at rette den. Og som et resultat, leverer den førsteklasses oplevelse til dine slutbrugere, som vil være i stand til at nyde interaktionen med din software uden uventede fejl i processen, og dermed bringe mere overskud til din virksomhed.