Unified API: Reducerea decalajului dintre aplicațiile SaaS

O interfață unificată de programare a aplicațiilor (API) este un API care servește ca un strat de abstractizare care poate comunica cu mai multe API-uri subiacente simultan.

Ca rezultat, fiecare obiect și punct final din API-ul unificat se mapează la un obiect și punct final corespunzător din API- ul de bază . Acest lucru permite companiilor SaaS să construiască o singură integrare cu API-ul unificat și să livreze instantaneu integrări cu fiecare dintre API-urile subiacente.

În acest articol, ne vom aprofunda în API-urile unificate, modul în care funcționează, provocările și caracteristicile lor și modul în care beneficiază companiile SaaS.

Ce problemă rezolvă API-urile unificate?

Cumpărătorii SaaS au ajuns să se aștepte la integrări native perfecte de la soluțiile pe care le achiziționează. Interoperabilitatea nu mai este un lucru plăcut, ci o cerință. Cu toate acestea, construirea acestor integrări native cu celelalte instrumente ale lor este o provocare cu care se confruntă fiecare companie SaaS astăzi, deoarece necesită resurse de inginerie semnificative pentru livrare și întreținere.

Pentru fiecare integrare, inginerii trebuie să creeze autentificare sigură, să parcurgă documentația API a aplicației terțe, să implementeze logica de afaceri necesară pentru a furniza cazul de utilizare și să construiască o experiență de configurare intuitivă pentru utilizatorul final.

Și acest lucru nu ține cont de toată munca implicată în menținerea și actualizarea integrării pe măsură ce se adaugă noi solicitări de caracteristici, atunci când API-ul terță parte lansează modificări de ultimă oră și timpul petrecut de dezvoltatori ajutând clienții să depaneze problemele de integrare.

În contextul integrărilor SaaS , API-urile unificate au apărut în ultimii ani ca o modalitate de a aborda provocarea de a înțelege documentația API-urilor fiecărei aplicații terțe.

În esență, acest lucru ar trebui să salveze echipele de ingineri de la învățarea sau revizuirea constantă a nuanțelor, formelor și nomenclaturii pentru fiecare API individual, o dată pentru fiecare integrare.

Cum funcționează API-urile unificate?

Să vedem cum funcționează un API unificat cu un exemplu tangibil.

Imaginați-vă că clienții dvs. solicită ca produsul dvs. să se integreze cu CRM - în baza dvs. de utilizatori, unii clienți folosesc Salesforce, alții folosesc HubSpot și unii folosesc Dynamics sau Pipedrive.

Un API CRM unificat ar abstrage API-urile fiecăruia dintre aceste CRM-uri prin menținerea referințelor la fiecare dintre API-urile CRM-urilor subiacente.

Sursa: Paragon

Exemplul de aici arată că fiecare CRM subiacent are un obiect care reprezintă un „contact”.

HubSpot îl numește Contact, Salesforce oferă atât un Lead, cât și un obiect Contact, iar Pipedrive se referă la contacte ca Perspectivi. Când se efectuează un apel către obiectul „Contact” din API-ul unificat, API-ul unificat va face referire la obiectul corespunzător din serviciul specificat.

Acum, referințele la nivel de obiect sunt primul strat, dar în cadrul acelor obiecte, există și proprietăți sau câmpuri care sunt abstracte. În exemplul de mai sus, aceasta ar putea include o nomenclatură diferită pentru nume, ID, companie etc.

Deci, dacă echipa dvs. construiește mai multe integrări CRM, teoretic, puteți construi o singură integrare cu un API CRM unificat care vă permite să livrați simultan toate integrările CRM subiacente.

API-uri unificate specifice categoriei

Nu toate API-urile pot fi unificate într-un singur API, deoarece diferite aplicații SaaS au modele de date, structuri și caracteristici unice.

Prin urmare, furnizorii oferă de obicei mai multe API-uri unificate care sunt specifice unei anumite verticale SaaS, cum ar fi CRM, contabilitate sau publicitate, deoarece aceste aplicații SaaS vor avea structuri de date relativ similare și vor împărtăși multe obiecte sau proprietăți comune.

Atunci când proiectează un API unificat, furnizorul de API trebuie să aleagă cu atenție ce API-uri de bază să includă în API-ul unificat, deoarece cu cât API-urile subiacente se suprapun mai mult, cu atât este mai largă acoperirea pe care API-ul unificat o poate oferi.

Cu toate acestea, dacă API-ul unificat ar include aplicații care nu sunt la fel de asemănătoare între ele, ar fi mai puțin util, deoarece nu ar putea evidenția toate obiectele și proprietățile pe care API-urile subiacente le partajează. De exemplu, un API unificat care include un CRM și o aplicație de contabilitate poate să nu fie foarte util, deoarece în afara unui obiect „client”, este posibil să nu existe prea multă suprapunere între restul modelelor de date ale aplicațiilor.

Care sunt beneficiile API-urilor unificate?

API-urile unificate oferă multiple beneficii echipelor de inginerie care trebuie să livreze și să mențină zeci de integrări.

abstracții API

În loc să învețe și să interacționeze cu API-urile individuale ale fiecărui serviciu, echipa dvs. de ingineri trebuie să învețe doar o singură dată (pe categorie) cum să interacționeze cu API-ul unificat.

Acest lucru nu numai că face construirea acestor integrări mai ușoară și mai rapidă, dar ajută și la reducerea complexității integrărilor.

În plus, când vine vorba de întreținere, furnizorul unificat de API este responsabil pentru gestionarea comunicării cu API-urile de bază, ceea ce înseamnă că echipa dvs. nu trebuie să-și facă griji cu privire la modificările întrerupte aduse unuia dintre API-urile de bază. În cele din urmă, furnizorul unificat de API va fi responsabil pentru actualizarea abstracției pentru a se asigura că integrarea continuă să funcționeze.

Autentificare gestionată

Furnizorii de API-uri unificate oferă, în general, un serviciu de autentificare gestionat care face abstractie de complexitatea autentificării cu API-urile subiacente, fie că este vorba de chei API sau OAuth.

Când vă integrați direct cu mai multe API-uri, trebuie să gestionați procesul de autentificare pentru fiecare, inclusiv gestionarea acreditărilor utilizatorului și asigurarea politicilor securizate de reîmprospătare a simbolurilor.

Având în vedere că există multe nuanțe în modul în care fiecare aplicație gestionează autentificarea, aceasta poate fi o sarcină greoaie și predispusă la erori, mai ales dacă lucrați cu un număr mare de API-uri.

Logare

Prin natură, API-ul unificat face solicitări de proxy către API-urile de bază. Ca atare, vor colecta și analiza date despre solicitările făcute către aplicațiile terțe. Ca urmare, atunci când o solicitare eșuează, furnizorul unificat de API poate înregistra acest eveniment și poate furniza detalii despre mesajul de eroare care a fost returnat de API-ul de bază.

Această funcționalitate de înregistrare poate fi utilă pentru echipa dvs., deoarece le permite să identifice rapid problemele care pot apărea cu integrările lor. În loc să parcurgă jurnalele de la mai multe API-uri terțe, ei se pot baza pe furnizorul unificat de API pentru a centraliza înregistrarea și raportarea erorilor.

Cu erori de depanare, furnizorii de API unificați pot furniza adesea mesaje de eroare mai detaliate decât API-urile de bază în sine. Acest lucru se datorează faptului că pot analiza răspunsul la erori și pot oferi mai mult context în jurul cauzei principale a problemei, ceea ce poate reduce foarte mult timpul petrecut cu diagnosticarea erorilor și poate accelera timpul de răspuns la incident .

Interfață de utilizator pre-construită

Majoritatea furnizorilor de API unificați oferă o interfață pre-construită pentru ca clienții tăi să se autentifice într-o integrare, scutindu-te de a construi singur experiența de configurare.

Acest lucru vă eliberează echipa de la proiectarea experienței utilizatorului pentru fiecare integrare, ceea ce se poate accentua în ceea ce privește economisirea de timp atunci când luați în considerare zecile de integrări potențiale pe care le puteți construi pe API-ul unificat.

Care sunt provocările legate de utilizarea API-urilor unificate?

În timp ce API-urile unificate oferă beneficiile împărtășite mai sus, ele sunt afectate de unele limitări structurale de care companiile încep să devină mai conștiente.

Limitări ale cazurilor de utilizare

Având în vedere că API-urile unificate pot abstrage doar obiectele și punctele finale „partajate” dintre API-urile subiacente, puteți construi doar caracteristici care sunt relativ simple și generalizabile în toate integrările. Aceasta este de departe cea mai mare limitare a oricărei soluții API unificate.

În plus, cu cât sunt mai multe aplicații acceptate într-un API unificat, cu atât acesta devine mai limitat.

Sursa: Paragon

Să trecem prin câteva exemple ale acestor limitări.

Caracteristici ireconciliabile

Dacă trebuie să construiți o caracteristică de integrare care implică funcționalități sau proprietăți specifice uneia dintre integrări, acest lucru nu va fi posibil cu un API unificat.

De exemplu, să presupunem că doriți să vă integrați cu mai multe instrumente de feedback ale clienților printr-un „API de feedback unificat”. Dacă un instrument folosește un model cantitativ cu scoruri de feedback între 1-10, în timp ce altul colectează doar „negative, neutre, pozitive” însoțite de „note”, nu există nicio modalitate ca un API unificat să poată sprijini acele cazuri de utilizare, deoarece nu puteți reconcilia acelea într-o singură referință.

Câmpuri lipsă

Dacă proprietatea pe care trebuie să o actualizați prin integrare este disponibilă numai pentru un anumit subset al integrărilor acceptate, acea proprietate nu va fi disponibilă în API-ul unificat.

De exemplu, chiar dacă câteva dintre aplicațiile terță parte subiacente au cod poștal ca câmp, atâta timp cât unul nu are, codul poștal nu poate fi accesat ca proprietate prin API-ul unificat.

Obiecte și câmpuri personalizate

Prin natura lor, API-urile unificate oferă un set de referințe predefinite la fiecare API-ul de bază. Cu toate acestea, dacă introduceți obiecte sau câmpuri personalizate în amestec, furnizorul API unificat nu poate anticipa care sunt acele obiecte sau câmpuri. Prin urmare, nu pot suporta integrări care implică obiecte sau câmpuri personalizate.

Acesta poate fi un blocant uriaș dacă clienții dvs. necesită integrările pe care le furnizați pentru a sprijini utilizarea obiectelor personalizate în cadrul aplicațiilor terțe.

Limitele ratelor

Atunci când integrați simultan cu mai multe API-uri printr-un API unificat, trebuie să fiți conștienți de limitele ratei fiecărui API și să vă asigurați că logica dvs. de integrare nu depășește limitele pentru niciun API.

Aceasta înseamnă că logica pe care o construiți trebuie să respecte limitele de rată ale API-ului cu cel mai mic prag pentru limitele de rată. Mai simplu spus, API-ul cu cea mai mică limită de rată va fi factorul limitativ pentru integrarea dvs. Dacă încercați să faceți prea multe solicitări către punctele finale ale API-ului respectiv, solicitările dvs. vor începe să eșueze, chiar dacă celelalte API-uri din API-ul unificat pot suporta din punct de vedere tehnic același volum.

Pentru a evita atingerea erorilor de limitare a ratei atunci când faceți solicitări în bloc către anumite puncte finale pentru acele integrări, trebuie să utilizați loturi sau limitarea pentru a controla rata de solicitări pe care le trimiteți către fiecare API.

Așadar, deși este încă posibil să rezolvați limitele mai mici ale ratei, vă veți descoperi că construiți o complexitate suplimentară în baza de cod pentru a face față limitărilor oricăreia dintre integrările de bază.

Securitate

API-urile unificate necesită, în general, să autorizați accesul la toate domeniile pentru un serviciu terță parte pentru a le utiliza API-ul, spre deosebire de a vă permite să selectați domenii individuale pentru fiecare integrare.

Aceasta înseamnă că atunci când autentificați un utilizator pentru a utiliza integrarea dvs., acesta va fi forțat să vă ofere acces la toate datele asociate cu acel serviciu terță parte, nu doar la datele necesare pentru integrare.

De exemplu, construiți o integrare CRM printr-un API unificat, iar CRM are acces la datele de vânzări, marketing și asistență pentru clienți. Când un utilizator își autentifică contul pentru a utiliza integrarea dvs., vi se va acorda acces la toate cele trei seturi de date, chiar dacă aplicația dvs. are nevoie doar de datele de vânzări.

Acest lucru poate ridica probleme de securitate pentru clienții dvs. Pentru a atenua aceste preocupări, este important să fii transparent cu utilizatorii cu privire la datele la care solicitați acces și să explicați clar de ce aveți nevoie de aceste date.

În plus, având în vedere că furnizorul găzduiește în general API-uri unificate, vă bazați pe furnizor pentru a vă asigura că are măsuri de securitate puternice pentru a proteja datele utilizatorilor dvs. de accesul neautorizat sau de încălcări.

Model de date cu opinie

Modul în care furnizorul reconciliază diferitele API-uri subiacente și punctele finale de referință depinde de propria opinie. Deși aceasta nu este o problemă pentru majoritatea cazurilor de utilizare, vor exista momente în care acestea pot prezenta o abstractizare cu care nu sunteți de acord sau care nu aderă la comportamentul așteptat.

Constrângeri ale foii de parcurs

În comparație cu platformele de integrare încorporate , care oferă abstracții unu-la-unu ale fiecărui API terță parte din mai multe categorii, furnizorii de API-uri unificate sunt restricționați la categoriile pentru care au creat API-uri unificate.

Deși pot și vor construi noi API-uri unificate în timp, dacă solicitați o integrare cu o categorie care nu este acceptată în prezent, sunt șanse să trebuiască să așteptați ani de zile pentru ca această integrare să fie disponibilă.

Singura excepție ar fi dacă furnizorul s-a întâmplat să creeze un API unificat pentru categoria în care se încadrează integrarea solicitată. Totuși, având în vedere amploarea ecosistemului SaaS și potențialele categorii pe care le-ar putea susține, acesta va fi rareori cazul.

Când ar trebui să utilizați un API unificat

Când vine vorba de a decide dacă un API unificat este soluția potrivită pentru echipa ta, poți urma criterii simple de luare a deciziilor.

Dacă nu puteți spune da cu încredere celor patru puncte de mai sus, este posibil să nu doriți să fiți blocat în utilizarea unui API unificat.

În schimb, un Platforma de integrare încorporată poate fi o soluție mai bună, deoarece vă permit să construiți integrări mult mai profunde, oferind în același timp instrumente mai cuprinzătoare pentru a ajuta la eficientizarea procesului de dezvoltare a integrării.

Provocarea integrării B2B SaaS

Decizia unei soluții care să vă ajute să scalați foaia de parcurs de integrare nativă a produsului SaaS nu este una ușoară. Nu trebuie doar să vă asigurați că poate aborda cazurile dvs. de utilizare astăzi, ci și toate cazurile de utilizare posibile pe care clienții dvs. le pot solicita în viitor.

API-urile unificate pot fi o soluție excelentă pentru livrarea a zeci de integrări cu un efort minim, cu condiția ca cazurile de utilizare pe care clienții dumneavoastră le solicită să fie uniforme pentru fiecare integrare dintr-o anumită categorie.

Este o piață în curs de dezvoltare cu mulți jucători noi și este cu siguranță o abordare interesantă pentru rezolvarea provocării integrării B2B SaaS.

Aflați totul despre API-uri, beneficiile, provocările și cazurile de utilizare ale acestora în ghidul cuprinzător.