Mentalitatea platformei în managementul produselor API

Nu este un secret pentru nimeni că pandemia a amplificat în mod semnificativ nevoia organizațiilor de a adopta o strategie digitală. Transformările digitale care au fost deprioritate în favoarea altor obiective organizaționale s-au mutat peste noapte în prim-plan, cu o urgență fără precedent. Potrivit unui sondaj global McKinsey din 2020 al directorilor, companiile au accelerat ritmul cu care au digitalizat operațiunile interne și și-au extins portofoliile de produse digitale cu câțiva ani, în ciuda provocărilor semnificative generate de COVID-19.

În centrul acestor transformări digitale se află integrarea, facilitată de interfețele de programare a aplicațiilor (API). Odinioară considerate pur și simplu „mesageri” sau „intermediari” care transmiteau date între sistemele software, API-urile sunt acum recunoscute ca „țesutul conjunctiv” al ecosistemelor digitale, oferind integrare nelimitată și oportunități de afaceri organizațiilor care le construiesc și le folosesc. Datorită potențialului unic pe care îl reprezintă API-urile, managerii de produs care le supraveghează dezvoltarea trebuie să adopte o abordare care să le deblocheze valoarea latentă, una care să pună accent pe flexibilitate și extensibilitate pentru a asigura experiențe de integrare impecabile.

Fă mai mult cu mai puțin

Chiar înainte de ultimul an fără precedent, valoarea API-urilor pentru organizații a fost bine documentată, iar economia API-urilor a prosperat de ceva timp. Pentru a înțelege peisajul integrărilor de astăzi, este util să explorezi originile filozofiei Best of Breed (BoB). Înainte de anii 1990, furnizorii de software comercializau soluții de suită de planificare a resurselor întreprinderii (ERP) care încercau să rezolve o mare varietate de provocări organizaționale. Din ce în ce mai mult, aceste suite au ajuns să fie considerate greoaie și nepractice, deoarece nu au reușit să abordeze cazurile de utilizare specifice organizației. Ca rezultat, furnizorii au început să construiască instrumente mai concentrate care au rezolvat provocările pentru o zonă funcțională, în loc de apartamente mai mari care încercau să facă totul pentru toată lumea. Întreprinderile au salutat ideea de a alege dintr-o varietate de instrumente mai mici și mai specializate și au început să adune colecții de soluții individuale care se potriveau cel mai bine nevoilor lor specifice.

Unind punctele

Pe măsură ce abordarea BoB a câștigat avânt, integrările au devenit o parte crucială a strategiilor de produs. Un instrument care a fost excelent la rezolvarea problemelor pentru o zonă a unei afaceri trebuia să se poată integra bine cu alte produse BoB care ar fi probabil să fie utilizate împreună cu acesta. Luați în considerare HubSpot, software-ul de vânzări și CRM implementat de organizații pentru a urmări și optimiza conductele de vânzări și relațiile cu clienții. HubSpot se integrează cu ușurință cu alte software-uri BoB, cum ar fi DocuSign (semnături digitale), Twilio (notificări prin e-mail/SMS) și Zendesk (asistență pentru clienți), fără a necesita dezvoltare suplimentară din partea echipelor de inginerie ale clientului.

Nevoia de instrumente complementare care să se conecteze perfect unul la altul a fost însoțită de o schimbare la nivel de industrie către adoptarea deschiderii, mai degrabă decât limitarea interacțiunilor dintre sisteme. Undeva, pe parcurs, numărul de integrări suportate de un produs a devenit o măsură care merită marketing.

Propunerea platformei

Cu toate acestea, adevărata valoare a integrărilor depășește capacitatea lor de a coordona instrumente și sisteme disparate. În cel mai bun caz, API-urile sunt mecanismul colectiv pentru transformarea produselor în platforme. Produsele, prin definiție, sunt instrumente care au o aplicație specifică; de aici „aplicații”. Ele sunt limitate în capacitatea lor de a crea mai multe propuneri de valoare și, prin extensie, mai multe fluxuri de venituri. Platformele, pe de altă parte, adaugă valoare într-un mod diferit: furnizând stratul de infrastructură pe care pot fi construite numeroase produse.

API-urile deschid noi canale de afaceri prin valorificarea expertizei terților care le folosesc. Dezvoltatorii consumatori pot proiecta o aplicație imobiliară care utilizează API-urile Google Maps pentru a ajuta utilizatorii să vâneze case sau pot folosi API-urile Skyscanner Flight și API-urile Hotel Expedia pentru a crea un site de ecoturism specializat în călătoriile într-o anumită locație. Acești dezvoltatori și parteneri externi beneficiază de accesul la datele și serviciile existente pe care le pot adapta pentru afacerile lor, iar proprietarii de API-uri precum Expedia își extind acoperirea și monetizează oportunități care nu ar exista dacă ar continua, să zicem, să listeze doar hoteluri în produsul lor.

Făcându-l modular

Pentru liderii de produse, dezvoltarea unei strategii API de succes necesită o schimbare a mentalității de la gândirea de produs la gândirea de platformă. Aceasta înseamnă construirea produselor într-un mod modular, deschis, care să permită recombinarea funcționalității acestora și care acordă prioritate flexibilității pentru dezvoltatorii consumatori. Gândiți-vă la sistemele de rafturi IKEA, pe care clienții le pot achiziționa, asambla și personaliza în diferite moduri pentru a satisface o varietate de nevoi. Managerii buni de produse API văd API-urile așa cum sunt: ​​instrumente pentru extinderea afacerii și dezvoltarea parteneriatelor valoroase. Recunoașterea acestui potențial înseamnă implementarea celor mai bune practici pentru a asigura adoptarea.

Încântarea dezvoltatorilor

Dacă există un pilon de bază al unei strategii solide API, acesta este experiența dezvoltatorului (DX). Pentru integrările API, managerii de produs „clienți” pe care trebuie să-i încânte sunt dezvoltatorii consumatoare. Aceștia sunt utilizatorii care apelează/se integrează în cele din urmă cu un API, potențialii parteneri care pot ajuta la realizarea unei viziuni de produs la platformă. Etichetarea experienței lor „DX” în loc de „UX” recunoaște că ei nu sunt utilizatori finali obișnuiți – sunt mult mai abili din punct de vedere tehnic. Pentru a empatiza cu ei, este esențial să le înțelegem nevoile și așteptările specifice.

Cele mai bune practici

Următoarele, deși nu reprezintă în niciun caz o listă exhaustivă, sunt practici esențiale pentru construirea de API-uri de primă clasă care asigură experiențe de integrare fără fricțiuni și consistente, previzibile pentru dezvoltatorii consumatori. Managerii de produs ar trebui să abordeze proiectarea API-urilor într-o manieră scalabilă, definind un cadru de bune practici și publicându-l ca un document la care echipele se pot referi atunci când construiesc noi API-uri.

Convenții de denumire și puncte finale consistente

Stabilirea unor convenții de denumire coerente pentru punctele finale API care identifică în mod clar natura și scopul API-ului elimină ambiguitatea și contribuie la un DX pozitiv și previzibil. Cel mai bine este să alegeți o adresă URL de bază comună pentru toate API-urile și un cadru pentru URL-ul final care evită jargonul și abrevierile. API-urile nordice oferă o listă utilă de sfaturi pentru denumirea punctelor finale.

Structuri detaliate de răspuns pentru succes și eșec

Dezvoltatorii doresc și se așteaptă la obiecte de date familiare și coduri de stare pentru răspunsuri de succes și eșec. Aceasta înseamnă un cod de stare 2xx pentru scenariile de succes, un cod 4xx pentru eșecurile de pe partea clientului și un cod 5xx pentru erorile pe partea de server. Cu toate acestea, specificitatea este cheia. Un apel către un API „trimitere e-mail” care returnează pur și simplu un răspuns 4xx fără informații suplimentare face o experiență slabă pentru dezvoltatori, deoarece confirmă doar că eroarea a fost în solicitarea clientului, fără a oferi informații suplimentare despre ce anume a mers prost.

 { "status": 400, "message": "incorrect request" }

În schimb, un răspuns care oferă detalii specifice în format care poate fi citit de om și sub forma unui cod de eroare unic poate ajuta dezvoltatorii să decidă rapid cum să remedieze scenariul de eroare, să scrie cod pentru a rezolva problema și să reîncerce apelul API.

 { "status": 400, "message": "To recipient not specified", "code": 21221 }

Pentru DX optim, structurile de răspuns și cheile care comunică starea ar trebui să fie consecvente între API-uri. De exemplu, câmpul de cod de eroare din cele de mai sus ar trebui să fie denumit invariabil „cod” în fiecare API, nu „cod” în unele API și „cod de eroare” în altele.

Limite de rată configurabile

Limitele ratei guvernează cât de accesibil este un API, determinând de câte ori îl poate apela un utilizator într-o singură unitate de timp. Limitele de tarife prea mari pot inunda sistemele cu un număr de solicitări incontrolabil care degradează performanța, în timp ce limitele de rate nerezonabil de scăzute pot face ca tranzacțiile în așteptare să rămână în coadă în sistemele utilizatorilor. Ambele contribuie la un DX slab. Atunci când proiectați API-uri, cel mai bine este să permiteți limite de rată care pot fi ajustate în funcție de cazuri și circumstanțe de afaceri specifice. Clienții cu volum mare, de exemplu, pot avea o nevoie reală de a apela mai des API-urile.

Pentru a determina cel mai bine limitele de rată adecvate, este util să grupați mai întâi API-urile în categorii semnificative, în funcție de frecvența și volumul cu care sunt apelate. De exemplu, API-urile care configurează datele primare ale clienților (crearea profilului/contului) sunt apelate mai rar și pot gestiona limite mai mici ale ratei, în timp ce API-urile pentru tranzacții („creare comandă”, „trimite e-mail”) sunt apelate mai frecvent, necesitând limite mai mari ale ratei. Stabilirea categoriilor sau nivelurilor pentru diferite cazuri de utilizare face ca API-uri să fie mai fiabile și mai scalabile. Pentru un exemplu de limite de rată clar definite, consultați documentația API-ului Slack.

Documentație cuprinzătoare

Documentația servește ca manual de utilizare pentru un API. Le explică în mod clar dezvoltatorilor ce face un API, cum să îl folosească și la ce să se aștepte de la el. Documentația bună este scrisă într-un limbaj clar, accesibil, este detaliată și interactivă și oferă o mulțime de demonstrații și fragmente de cod pentru a simplifica integrarea. În acest fel, facilitează o integrare ușoară și un Time to First Hello World (TTFHW), o măsură importantă care reprezintă cât de rapid poate un dezvoltator să apeleze cu succes primul lor API.

Documentația ar trebui să identifice în mod clar care câmpuri din solicitarea API sunt obligatorii și care sunt opționale, precum și lungimea minimă și maximă și tipul de date pentru acele câmpuri. În esență, ar trebui să includă tot ceea ce este necesar pentru a stabili așteptări și pentru a elimina obstacolele pentru dezvoltatorii consumatori. Dezvoltatorii care creează scheme de baze de date în sistemele lor, de exemplu, nu ar trebui să fie nevoiți să ajusteze ulterior lungimea coloanelor din tabele, deoarece documentația nu specifica parametrii.

Documentația API poate crește gradul de adopție nu numai că servește ca referință de încredere pentru dezvoltatorii consumatori, ci și acționând ca un instrument de marketing pentru API-ul în sine. Adesea, prima persoană care întâlnește documentația API este o parte interesată care se confruntă cu afaceri, care o răsfoiește în fazele inițiale ale evaluării produsului. Prin urmare, nu ar trebui să includă numai detalii despre elementele tehnice ale API-ului, ci ar trebui, de asemenea, să articuleze în mod clar cazurile de utilizare în afaceri pe care API-ul le face posibile.

Există o serie de instrumente pe piață care pot ajuta la generarea de documentație API cuprinzătoare. Revizuirea exemplelor de documentație de înaltă calitate, cum ar fi cea a lui Stripe, este, de asemenea, utilă.

Aducând totul împreună

Integrările reprezintă un domeniu vast, cu multe componente, dar înțelegerea principiilor de bază ale unui API bun este fundamentală pentru dezvoltarea unei strategii solide. API-urile sunt mult, mult mai mult decât simpli conectori de sistem. Ele sunt elementele de bază ale rețelelor digitale expansive și cheile pentru deschiderea de noi fluxuri de venituri și eliberarea de valoare neexploatată. Din acest motiv, o strategie API de succes nu se referă doar la construirea de produse; este vorba despre construirea potențialului. Un manager de produs API trebuie să adopte o mentalitate de platformă și să prioritizeze factorii care vor ușura adoptarea de către potențialii parteneri care își pot lua apoi API-ul, integra și rula cu acesta.