Erori API obișnuite și cum să le remediați

Când construiți orice software, fie că este un site web sau o aplicație, este o necesitate să includeți asigurarea calității în ciclul dvs. de dezvoltare software. Dacă este ratată, există șanse mari de a elibera instanțe cu erori care cu siguranță vor strica experiența utilizatorului final.

Nicio parte interesată nu și-ar dori vreodată să se întâmple asta. De aceea, testarea rămâne în gardă pentru lansări de succes și asigură un răspuns pozitiv la funcțiile pe care le adăugați. Aceasta implică cele mai frecvente scenarii de utilizare pentru a verifica dacă fluxurile funcționează conform așteptărilor înainte ca oricare dintre clienții tăi reali să aibă ocazia să-l verifice.

Când vă gândiți ce teste să includeți în suita dvs. de acoperire, acordați atenție testării API, deoarece este unul dintre cele mai importante și utilizate pe scară largă tipuri. API-urile (Application Programming Interfaces) sunt prezente în orice aplicație și sunt responsabile pentru comunicarea corectă între mai multe sisteme software. Principalele funcții ale API-urilor includ specificarea solicitărilor de date care pot fi transmise și a condițiilor pentru ca aceste solicitări să fie procesate. 

De exemplu, un utilizator dorește să adauge un articol într-un coș, apasă un buton corespunzător care declanșează o solicitare API, primește răspunsul și coșul este actualizat. Dacă această solicitare eșuează, funcția „adăugați în coș” se va întrerupe.

Acesta este modul în care problemele cu API-ul pot afecta afacerile, adăugând încă un factor important pentru care toată lumea ar trebui să-l testeze corect. Pentru a încorpora această testare, ar trebui să începeți cu instrumentele de testare API de automatizare potrivite pentru a vă asigura că nu trece nicio eroare.

Pot exista diferite erori API și aici vă vom spune mai multe despre 5 dintre cele mai populare: 

Metoda HTTP incorectă

Cea mai simplă, dar răspândită eroare API este metoda HTTP incorectă. Adesea, problema este cauzată de lacune în documentație. Unul dintre exemple poate fi trimiterea unei cereri GET care specifică opțiunea de date, dar săriți menționarea parametrului -X GET. Ca rezultat, este convertit automat într-o solicitare POST. De asemenea, problemele cu metodele HTTP pot apărea la comutarea instrumentelor API, deoarece unele dintre ele pot folosi o singură metodă pentru a crea medii de testare și pentru a le modifica, în timp ce altele folosesc căi separate pentru aceste acțiuni. De aceea, este important să verificați cu atenție aceste nuanțe, precum și să adoptați o abordare consecventă pentru redactarea propriei documentații. 

Folosind un protocol greșit

O altă eroare comună este discrepanțele dintre protocoalele https:// și http://. Unele API-uri pot accepta doar unul dintre protocoale, să spunem http, așa că specificarea https:// în acest caz va duce la procesarea incorectă a cererii. Chiar dacă ambele sunt acceptate, pot apărea probleme cu redirecționarea către https:// atunci când specificați http://. Cazul poate apărea și atunci când furnizorii de API-uri terțe pe care intenționați să le utilizați fac unele modificări și nu trimit o notificare în acest sens. Așa că este mai bine să verificați din nou aceste aspecte din când în când. Pentru a vă crea propriul API, este mai bine să utilizați protocolul https://. Pentru a face posibil, este necesar să instalați un certificat SSLcătre gazdă. Cu ceva timp în urmă, certificatele SSL erau puțin costisitoare, așa că ar putea exista îndoieli cu privire la ele, dar cu furnizori gratuiti precum Letsencrypt sau Cloudflare, devine mai ușor ca niciodată.

Absența mesajelor de eroare semnificative

Dacă v-ați confruntat vreodată cu o „ eroare API neașteptată”, știi cât de enervant poate fi acesta. De obicei, mesajele de eroare ar trebui să faciliteze depanarea dezvoltatorilor, indicând motivul exact al erorii sau cel puțin unde să o caute. Din păcate, astfel de erori neinformative pot duce la ore de timp pierdut, pot crește timpul necesar pentru a rezolva eroarea și, în consecință, pot provoca o creștere mai mare a feedback-ului negativ pe care îl primiți, de aceea este mai bine să petreceți puțin mai mult timp descrierii potențialului. erori și făcând mesajele informative pentru cei care vor trebui să le depaneze. Deși există câteva zeci de coduri de eroare HTTP, nu este necesar să le folosiți pe toate, ci să păstrați codurile de eroare standard (200,400 și 500) și să luați în considerare includerea indicațiilor în mesaje, astfel încât chiar și în cazurile în care ceva nu funcționează,

Probleme de autorizare

Poate părea că aici totul este clar, deoarece autorizarea greșită presupune de obicei că numele de utilizator sau parola sunt incorecte, dar, de fapt, chiar și confundarea „autorizare” cu „autentificare” în anteturi provoacă eroarea. Este valabil mai ales în utilizarea protocolului OAuth 2. De asemenea, sintaxa contează, deoarece unele lucruri simple, dar mai puțin evidente, pot crea confuzie. În cele mai multe cazuri, acestea sunt simbolul purtător, spațiul din prefixul „De bază”, lipsește pentru a adăuga complet acest prefix și pierzând două puncte în perechea „nume utilizator: parolă”. Chiar și atunci când numele de utilizator este folosit singur în unele API-uri care nu necesită parola, va trebui totuși să utilizați aceste două puncte.

Nu se specifică anteturile Content-Type și Accept

Unele API-uri sunt tolerante la solicitările în care anteturile nu conțin Content-Type sau antetul Accept, dar corespund formatului de date permis. Alții sunt mai scrupuloși și nu vor lăsa cererea să transmită codul de eroare 403 Permisiune refuzată. În această etapă se stabilește interacțiunea dintre client și server cu privire la tipul de date așteptat în cerere și răspuns. Această verificare a antetului este implementată pentru a reduce riscurile de încălcare a securității și tentative generale de hacking, de aceea este mai bine să specificați aceste anteturi pentru a evita orice probleme în timpul utilizării.

Învelire

Efectuarea testării API împreună cu celelalte tipuri de testare, inclusiv regresia, testul de fum și, bineînțeles, testarea unitară în timpul sprinturilor de dezvoltare, vă va ajuta lansarea software-ului să aibă loc mai rapid. Logica din spatele acestuia este simplă: cu cât se observă mai devreme o eroare, un defect sau o inconsecvență cu cerințele afacerii, cu atât este mai ușor să o remediați. Și, ca rezultat, oferiți o experiență de top utilizatorilor dvs. finali, care se vor putea bucura de interacțiunea cu software-ul dvs. fără erori neașteptate în proces, aducând astfel mai mult profit afacerii dvs.