Errori API comuni e come risolverli

Quando si crea un software, sia esso un sito Web o un'applicazione, è necessario includere la garanzia della qualità nel ciclo di sviluppo del software. Se viene perso, ci sono alte possibilità di rilasciare istanze con bug che rovineranno sicuramente l'esperienza dell'utente finale.

Nessuno stakeholder vorrebbe mai che ciò accadesse. Ecco perché i test restano in guardia per le versioni di successo e garantiscono una risposta positiva alle funzionalità che aggiungi. Ciò comporta gli scenari di casi d'uso più comuni per verificare che i flussi funzionino come previsto prima che uno qualsiasi dei tuoi clienti reali abbia l'opportunità di verificarlo.

Quando consideri quali test includere nella tua suite di copertura, presta attenzione ai test API, poiché è uno dei tipi più importanti e ampiamente utilizzati. Le API (Application Programming Interfaces) sono presenti in qualsiasi applicazione e sono responsabili della corretta comunicazione tra più sistemi software. Le principali funzioni delle API includono la specifica delle richieste di dati che possono essere trasmesse e le condizioni per l'elaborazione di tali richieste. 

Ad esempio, un utente desidera aggiungere un articolo a un carrello, preme un pulsante corrispondente che attiva una richiesta API, riceve la risposta e il carrello viene aggiornato. Se questa richiesta non riesce, la funzione "aggiungi al carrello" si interromperà.

È così che i problemi con l'API possono influire sul business, aggiungendo un altro fattore importante per cui tutti dovrebbero testarlo correttamente. Per incorporare questo test, si dovrebbe iniziare con i giusti strumenti di test dell'API di automazione per assicurarsi che nessun errore passi attraverso.

Possono esserci diversi errori API e qui ti diremo di più sui 5 più popolari: 

Metodo HTTP errato

L'errore API più semplice, ma ampiamente diffuso, è il metodo HTTP errato. Spesso il problema è causato da lacune nella documentazione. Uno degli esempi potrebbe essere l'invio di una richiesta GET specificando l'opzione dati, ma salta la menzione del parametro -X GET. Di conseguenza, viene automaticamente convertito in una richiesta POST. Inoltre, possono verificarsi problemi con i metodi HTTP quando si cambiano gli strumenti API perché alcuni di essi possono utilizzare un metodo per creare ambienti di test e modificarli, mentre altri utilizzano metodi separati per queste azioni. Ecco perché è importante controllare attentamente queste sfumature e adottare un approccio coerente per scrivere la propria documentazione. 

Utilizzo del protocollo sbagliato

Un altro errore comune sono le discrepanze tra i protocolli https:// e http://. Alcune API possono supportare solo uno dei protocolli, diciamo http, quindi specificare https:// in tal caso comporterà un'elaborazione errata della richiesta. Anche se entrambi sono supportati, potrebbero esserci problemi con il reindirizzamento a https:// quando specifichi http://. Il caso può verificarsi anche quando i fornitori di API di terze parti che prevedi di utilizzare apportano alcune modifiche e non inviano una notifica al riguardo. Quindi è meglio ricontrollare questi aspetti di volta in volta. Per creare la tua API, è meglio usare il protocollo https://. Per renderlo possibile, è necessario installare un certificato SSLall'ospite. Qualche tempo fa i certificati SSL erano un po' costosi quindi potrebbero esserci dei dubbi al riguardo, ma con provider gratuiti come Letsencrypt o Cloudflare, diventa più facile che mai.

Assenza di messaggi di errore significativi

Se hai mai riscontrato un " errore API imprevisto”, sai quanto possa essere fastidioso questo. Di solito, i messaggi di errore dovrebbero facilitare la risoluzione dei problemi per gli sviluppatori indicando il motivo esatto dell'errore o almeno dove cercarlo. Sfortunatamente, tali errori non informativi possono comportare ore di perdita di tempo, aumentare il tempo necessario per risolvere l'errore e, di conseguenza, causare un picco maggiore nel feedback negativo che ricevi, ecco perché è meglio dedicare un po' più di tempo alla descrizione del potenziale errori e rendendo i messaggi informativi per coloro che avranno bisogno di risolverli. Sebbene esistano diverse dozzine di codici di errore HTTP, non è necessario utilizzarli tutti, ma mantenere i codici di errore standard (200.400 e 500) e considerare di includere i suggerimenti nei messaggi in modo che anche nei casi in cui qualcosa non funziona,

Problemi di autorizzazione

Può sembrare che qui tutto sia chiaro in quanto un'autorizzazione errata di solito presuppone che il nome utente o la password non siano corretti, ma in realtà anche confondere "autorizzazione" con "autenticazione" nelle intestazioni causa l'errore. È particolarmente valido nell'utilizzo del protocollo OAuth 2. Inoltre, la sintassi è importante, perché alcune cose semplici ma meno ovvie possono creare confusione. Nella maggior parte dei casi, si tratta del token al portatore, lo spazio nel prefisso "Base", mancante per aggiungere completamente questo prefisso e perdendo i due punti nella coppia "nome utente: password". Anche quando il nome utente viene utilizzato da solo in alcune API che non richiedono la password, sarà comunque necessario utilizzare questi due punti.

Impossibile specificare le intestazioni Content-Type e Accept

Alcune API sono tolleranti alle richieste in cui le intestazioni non contengono Content-Type o Accept ma corrispondono al formato dati consentito. Altri sono più scrupolosi e non lasceranno la richiesta fornendo il codice di errore 403 Permission Denied. In questa fase viene stabilita l'interazione tra il client e il server in merito al tipo di dati previsto nella richiesta e nella risposta. Questo controllo dell'intestazione è implementato per ridurre i rischi di violazioni della sicurezza e tentativi di hacking complessivi, ecco perché è meglio specificare queste intestazioni per evitare problemi durante l'uso.

Incartare

L'esecuzione di test API insieme ad altri tipi di test, inclusi regressione, test del fumo e, naturalmente, test unitari durante gli sprint di sviluppo aiuterà il rilascio del tuo software a avvenire più velocemente. La logica alla base è semplice: prima si nota un bug, un difetto o un'incoerenza con i requisiti aziendali, più facile sarà risolverlo. E, di conseguenza, offri un'esperienza di prim'ordine ai tuoi utenti finali che potranno godere dell'interazione con il tuo software senza bug imprevisti nel processo, portando così maggiori profitti alla tua attività.