Veelvoorkomende API-fouten en hoe u ze kunt oplossen

Bij het bouwen van een stukje software, of het nu een website of applicatie is, is het een must om kwaliteitsborging op te nemen in uw softwareontwikkelingscyclus. Als het wordt gemist, zijn er grote kansen op het vrijgeven van buggy-instanties die de ervaring van de eindgebruiker zeker zullen bederven.

Geen enkele belanghebbende zou dit ooit willen. Daarom blijft testen op zijn hoede voor succesvolle releases en zorgt het voor een positieve reactie op de functies die u toevoegt. Dit omvat de meest voorkomende gebruiksscenario's om te controleren of de stromen werken zoals verwacht voordat een van uw echte klanten de kans krijgt om het te controleren.

Wanneer u overweegt welke tests u in uw dekkingspakket wilt opnemen, let dan op API-testen, aangezien dit een van de belangrijkste en meest gebruikte typen is. API's (Application Programming Interfaces) zijn aanwezig in elke applicatie en zijn verantwoordelijk voor de goede communicatie tussen verschillende softwaresystemen. De belangrijkste functies van API's zijn onder meer het specificeren van de gegevensverzoeken die kunnen worden verzonden en de voorwaarden waaronder deze verzoeken moeten worden verwerkt. 

Een gebruiker wil bijvoorbeeld een item aan een winkelwagentje toevoegen, drukt op een overeenkomstige knop die een API-verzoek activeert, ontvangt het antwoord en het winkelwagentje wordt bijgewerkt. Als dit verzoek mislukt, wordt de functie "toevoegen aan winkelwagen" verbroken.

Dat is hoe problemen met API van invloed kunnen zijn op het bedrijfsleven, en er wordt nog een belangrijke factor toegevoegd waarom iedereen het goed zou moeten testen. Om deze tests op te nemen, moet men beginnen met de juiste API-testtools voor automatisering om ervoor te zorgen dat er geen fouten doorglippen.

Er kunnen verschillende API-fouten zijn, en hier zullen we u meer vertellen over de 5 meest populaire: 

Onjuiste HTTP-methode

De eenvoudigste, maar wijdverbreide API-fout is de onjuiste HTTP-methode. Vaak wordt het probleem veroorzaakt door hiaten in de documentatie. Een van de voorbeelden kan het verzenden van een GET-verzoek zijn waarin de gegevensoptie wordt gespecificeerd, maar sla de parameter -X GET over. Als gevolg hiervan wordt het automatisch geconverteerd naar een POST-verzoek. Ook kunnen de problemen met HTTP-methoden optreden bij het wisselen van API-tools, omdat sommige van hen één methode kunnen gebruiken om testomgevingen te maken en deze te wijzigen, terwijl andere voor deze acties afzonderlijke manieren gebruiken. Daarom is het belangrijk om deze nuances zorgvuldig te controleren en een consistente benadering te volgen bij het schrijven van uw eigen documentatie. 

Het verkeerde protocol gebruiken

Een andere veel voorkomende fout zijn de verschillen tussen de https://- en http://-protocollen. Sommige API's ondersteunen mogelijk slechts één van de protocollen, laten we zeggen http, dus het specificeren van https:// in dat geval zal leiden tot onjuiste verwerking van verzoeken. Zelfs als beide worden ondersteund, kunnen er problemen zijn met de omleiding naar https:// wanneer u http:// opgeeft. Het geval kan zich ook voordoen wanneer providers van API's van derden die u van plan bent te gebruiken enkele wijzigingen aanbrengen en daarover geen melding sturen. Het is dus beter om deze aspecten van tijd tot tijd opnieuw te controleren. Voor het maken van uw eigen API is het beter om het https://-protocol te gebruiken. Om dit mogelijk te maken, is het vereist om een ​​SSL-certificaat te installerennaar de gastheer. Enige tijd geleden waren SSL-certificaten een beetje duur, dus er kunnen twijfels over bestaan, maar met gratis providers zoals Letsencrypt of Cloudflare wordt het eenvoudiger dan ooit.

Afwezigheid van zinvolle foutmeldingen

Als u ooit een " onverwachte API-fout " heeft gehad', je weet hoe vervelend deze kan zijn. Gewoonlijk worden foutmeldingen verondersteld om het oplossen van problemen voor de ontwikkelaars te vergemakkelijken, waarbij ze de exacte reden voor de fout aangeven of op zijn minst waar ze moeten zoeken. Helaas kunnen dergelijke niet-informatieve fouten resulteren in uren aan verspilde tijd, waardoor de tijd die nodig is om de fout op te lossen, toeneemt en bijgevolg een grotere piek in de negatieve feedback die u ontvangt, is. Daarom is het beter om wat meer tijd te besteden aan het beschrijven van het potentieel fouten en maakt de berichten informatief voor degenen die ze moeten oplossen. Hoewel er tientallen HTTP-foutcodes zijn, is het niet verplicht om ze allemaal te gebruiken, maar bewaar de standaardfoutcodes (200.400 en 500) en overweeg om de hints in de berichten op te nemen, zodat zelfs in gevallen waarin iets niet werkt,

Autorisatie probleem

Het lijkt misschien dat hier alles duidelijk is, aangezien verkeerde autorisatie meestal veronderstelt dat de gebruikersnaam of het wachtwoord onjuist is, maar in feite veroorzaakt zelfs het verwarren van "autorisatie" met "authenticatie" in headers de fout. Het is vooral geldig bij het gebruik van het OAuth 2-protocol. Ook is de syntaxis van belang, omdat sommige eenvoudige maar minder voor de hand liggende dingen voor verwarring kunnen zorgen. In de meeste gevallen zijn dit de token aan toonder, de spatie in het voorvoegsel "Basic", die ontbreekt om dit voorvoegsel volledig toe te voegen, en de dubbele punt verliest in het paar "gebruikersnaam: wachtwoord". Zelfs als de gebruikersnaam alleen wordt gebruikt in sommige API's die het wachtwoord niet nodig hebben, moet u deze dubbele punt nog steeds gebruiken.

Het niet specificeren van de Content-Type en Accept headers

Sommige API's zijn tolerant voor verzoeken waarbij headers geen Content-Type of de Accept-header bevatten, maar overeenkomen met het toegestane gegevensformaat. Anderen zijn nauwgezetter en laten het verzoek niet toe door de foutcode 403 Permission Denied te geven. In dit stadium wordt de interactie tussen de client en de server met betrekking tot het verwachte gegevenstype in het verzoek en het antwoord tot stand gebracht. Deze headercontrole is geïmplementeerd om het risico op beveiligingsinbreuken en algehele hackpogingen te verkleinen. Daarom is het beter om deze headers te specificeren om problemen tijdens het gebruik te voorkomen.

Inpakken

Door API-tests uit te voeren samen met de andere testtypen, waaronder regressie, rooktest en natuurlijk unit-testen tijdens de ontwikkelingssprints, zal uw softwarerelease sneller plaatsvinden. De logica hierachter is simpel: hoe eerder een bug, defect of inconsistentie met de zakelijke vereisten wordt opgemerkt, hoe gemakkelijker het is om het op te lossen. En als resultaat levert u de eersteklas ervaring aan uw eindgebruikers, die zullen kunnen genieten van de interactie met uw software zonder onverwachte bugs in het proces, waardoor uw bedrijf meer winst maakt.