Diferențele dintre API-uri și mesagerie pentru comunicarea cu aplicațiile

Phil Wilkins | Cloud Developer Evangelist, Oracle | decembrie 2022

Software-ul trebuie să comunice cu alt software. Uneori, software-ul dintr-o parte a unei aplicații trebuie să solicite servicii sau să facă schimb de date cu o altă parte a aplicației. Sau o aplicație trebuie să solicite servicii ori să facă schimb de date cu o aplicație complet diferită.

Există două mecanisme tipice utilizate pentru aceste tipuri de comunicare: interfețele de programare a aplicațiilor (API-urile) și mesageria.

Uneori, diferențele dintre API-uri și mesagerie pot deveni derutante. Aceasta pentru că termenii sunt utilizați în multe moduri ambigue. Chiar și acronimul API are o semnificație explicită, dar, din motive pe care le vom explica mai jos, termenul a căpătat mai multe înțelesuri diferite. Mesageria este un termen utilizat adesea foarte vag pentru a acoperi aproape orice comunicare între diferite sisteme. Așadar, să clarificăm ce înseamnă, de fapt, API-urile și mesageria.

O definiție detaliată a API-urilor

În linii mari, un API este contractul care stabilește modul în care un software poate primi solicitări de servicii și răspunde la acestea. Contractul respectiv este stabilit de dezvoltatorii software-ului.

Pare simplu? Este, până la un punct. Practic, semnificația implicită a API-ului se poate schimba în funcție de subiectul conversației. Dacă luăm separat fiecare literă a acronimului, un API înseamnă o interfață sau un „contract” prin care un software poate interacționa cu alt software. Uneori, discuția despre API se axează pe calitățile sale arhitecturale de nivel înalt; uneori este foarte detaliată, descriind modurile specifice în care implementează dezvoltatorii API-ul.

Unele cărți și articole despre API folosesc analogia dintre acesta și o ușă, în care caracteristicile API-ului descriu ușa. De exemplu, poate fi ușa unui magazin, care se deschide automat, sau ușa unui seif de bancă, ultrasecurizată. Contractul unei aplicații – caracteristicile ușii – trebuie să poată răspunde la întrebări precum:

  • Ce face API-ul, la nivel înalt? În analogia noastră cu ușa, aceasta se deschide fără a fi nevoie ca utilizatorul să se oprească și să atingă ceva (ușă de magazin) sau accesul este controlat, pentru protejarea a ceea ce se află în spatele ușii (seif bancar)?
  • Ce payloaduri (date transmise) va trebui să accepte pentru ca software-ul să funcționeze? De exemplu, software-ul ar putea primi un număr de cont bancar și o autorizație de securitate, pentru a răspunde comunicând soldul din contul bancar respectiv.
  • Ce date trebuie transferate pentru funcționarea acestui serviciu? De exemplu, este important să stabiliți exact cum arată un număr de cont valid și o autorizație de securitate validă, precum și conținutul răspunsului. Detaliile contează aici; ambiguitatea poate duce la erori.
  • Care este adresa ușii? De obicei, aceasta înseamnă modul în care se formează identificatorul universal al resursei (URI) pentru solicitare. Așadar, cum se adresează solicitantul API-ului?
  • Ce protocoale vor fi utilizate pentru comunicare? Acestea pot fi atât tehnologii binecunoscute, cum ar fi HTTP sau FTP, cât și protocoale speciale, cum ar fi STOMP sau QUIC.
  • Ce termeni și condiții trebuie să respecte utilizatorul API? Aici poate fi vorba despre detaliile de criptare, limitarea frecvenței cu care se pot apela API-urile sau mecanisme de rambursare pentru serviciile comerciale.
  • Ce promite API? Aici se pot include garanțiile la nivel de serviciu pentru API, astfel încât o solicitare să fie confirmată sau onorată într-o anumită perioadă de timp.

Definirea mesageriei în dezvoltarea aplicațiilor

În timp ce API-urile stabilesc condițiile în care software-ul va trimite și va primi solicitări de servicii, mesageria este procesul de trimitere a informațiilor de la un sistem la altul. Cuvântul cheie este proces.

Gândiți-vă la aceasta astfel:

  • Mesageria se referă la procesul de transmitere a unor informații – mesajul – de la solicitantul de servicii la furnizorul de servicii (adesea prin intermediul unui terț, denumit broker).

    Pentru a utiliza o analogie din realitate, gândiți-vă la o companie care îi trimite unui client un mesaj text. Furnizorul de servicii trebuie să cunoască numărul de telefon al destinatarului, astfel încât operatorul de telefonie mobilă să poată transmite mesajul. Totuși, din perspectiva operatorului de telefonie, payloadul, în sine, poate fi orice. Acesta nu are nevoie să știe dacă mesajul text este în engleză, spaniolă, japoneză sau conține doar un emoji.

  • Mesageria se referă la toată activitatea din culise în scopul trimiterii mesajului de la expeditor către client.

    Nu este nevoie ca expeditorul și destinatarul să știe cum funcționează procesul de mesagerie; ambii au încredere că operatorii de telefonie și producătorii de telefoane inteligente și-au făcut treaba în mod corespunzător. Și, pe de altă parte, operatorul de telefonie nu are nevoie să știe ce conțin mesajele; acesta trebuie doar să se asigure că sunt livrate destinatarilor și că nu sunt trunchiate sau distorsionate.

Merită reiterat faptul că majoritatea platformelor de mesagerie nu se preocupă de conținutul mesajelor, atât timp cât acestea se încadrează în constrângerile tehnologice. Pentru a reveni la analogia noastră, pentru smartphone-uri și pentru operatorii de telefonie mobilă nu contează dacă textul este în engleză sau mesajul conține doar un emoji.

Vedeți mai multe detalii despre componența API-urilor, platformelor API și gestionării API-urilor.

API-urile și mesageria funcționează împreună în sistemele corporative

Sistemele software ale companiilor sunt constituite din mai multe procese executabile și, prin urmare, este necesară comunicarea între procese (IPC). În acest caz, pentru efectuarea unei tranzacții, comunicările pot fi complexe, necesitând mai multe apeluri cu mai multe API-uri și numeroase date formatate strict. Tranzacțiile respective trebuie gestionate cu atenție și finalizate în ordinea corectă, astfel încât să satisfacă o nevoie de afaceri.

De exemplu, gândiți-vă la o comandă plasată de un client. Procesul va trebui să acceseze baza de date a clienților; să interogheze baza de date cu stocurile, sistemul contabil, sistemul de generare a facturilor și sistemul de debitare a cardurilor bancare; să ajusteze stocul și contul clientului; să creeze o solicitare pentru depozit și să inițieze o solicitare de expediere – toate acestea trebuie efectuate în ordinea corectă și finalizate corect.

În trecut, aceste interacțiuni erau efectuate utilizându-se o formă de stocare partajată, cum ar fi un sistem de fișiere sau o bază de date. Cu toate acestea, în sistemele corporative mai moderne, procesele pot comunica direct unele cu altele, astfel încât viteza loc este mai mare, iar problemele sunt eliminate (de exemplu, cazul în care stocul pentru o comandă a fost alocat deja de comenzile anterioare).

Comportament sincron și asincron

Putem caracteriza comunicarea noastră ca fiind de natură sincronă sau asincronă. Comunicarea sincronă înseamnă că toate părțile implicate într-o comunicare trebuie să fie prezente și capabile să răspundă. În exemplul nostru cu comanda, sistemele implicate în plățile electronice trebuie să fie disponibile pentru interacționarea în timp real. În alte cazuri, comunicarea poate fi asincronă, permițând ca părțile din sisteme să comunice fără a fi prezente în același moment. Așa se întâmplă atunci când ne trimitem e-mailuri unii altora. Pentru ca o comunicare să funcționeze asincron, avem nevoie de implicarea unui intermediar, care să facă posibilă transmiterea informațiilor în ambele sensuri.

Pentru astfel de sisteme complexe de mesagerie corporativă, există diverse tipuri sau modele:

  • Magistrală de servicii. Magistrala de servicii face legătura între diferitele procese și efectuează organizarea între procesele respective, ca în cazul tranzacției complexe menționate anterior. Sistemele de magistrale de servicii încorporează de obicei caracteristici cu valoare adăugată, cum ar fi capacitatea de a traduce payloadurile dintr-un format în altul (din engleză în franceză, în analogia noastră cu mesajul text), de a direcționa mesajele în funcție de conținutul lor sau chiar de a lua anumite decizii pe baza stării tranzacției complexe. De exemplu, sarcinile A și B pot fi efectuate în paralel; sarcina C se efectuează dacă sarcina B s-a finalizat; dacă sarcinile B nu reușesc, se efectuează sarcina D; dacă sarcina D nu reușește, urmează intervenția umană.

    Mesageria în stilul unei magistrale de servicii este denumită uneori rețea inteligentă, datorită acelor informații adăugate despre direcționarea și programarea mesajelor de pe „conducta” dintre furnizori și consumatori. Aceasta mai este denumită și orchestrare.

    Diagrama unei magistrale de servicii, descrierea de mai josFurnizorul de mesaje apelează magistrala de servicii pentru a expedia un mesaj. Apoi, magistrala de servicii preia mesajul și îl direcționează către consumatori. În timpul direcționării, mesajul poate trece printr-un proces de transformare logică și filtrare.

    Un termen sinonim pentru magistrala de servicii este magistrală de mesaje. Când aceste tehnologii au evoluat prima dată și au devenit soluții de arhitectură orientată către servicii (SOA), au existat câteva diferențe între magistralele de mesaje și cele de servicii. În prezent, nu mai există nicio diferență. De fapt, pentru ambele, se utilizează tot mai frecvent denumirea prescurtată de magistrală.

  • Servicii web:în cel mai larg sens al termenului, serviciile web reprezintă comunicările sincrone directe dintre două procese, care utilizează de obicei protocoalele TCP și HTTP (sau variante precum HTTPS și HTTP/2). Conexiunea cu consumatorul și clientul se realizează ca punct-la-punct (deși se obișnuiește ca furnizorul să accepte mai multe conexiuni cu clienții simultan). Între cele două procese, pot exista proxy-uri (de la firewalluri de rețea la gateway-uri API și memorii cache web) și intermediari (switch-uri și routere) de rețea, dar nici furnizorul, nici consumatorul nu le vor percepe.

    Diagrama serviciilor web, descrierea de mai josFurnizorul de mesaje comunică direct cu consumatorul. Procesul de transmitere depinde de disponibilitatea ambelor părți.
  • Brokeri de mesaje:brokerii de mesaje sunt intermediari între furnizorii de mesaje și consumatorii de mesaje, având legături atât cu magistralele de servicii, cât și cu serviciile web.

    Brokerii se situează între expeditorul și destinatarii mesajelor, primind mesajele care se transmit și stocându-le până când acestea sunt accesate de către destinatari. Aceasta înseamnă că mesajele sunt transmise indiferent de disponibilitatea imediată a destinatarilor. Prin urmare, o astfel de comunicare este descrisă adesea ca asincronă sau de tip „trimite și uită”, deoarece aveți siguranța că mesajele vor fi livrate la un moment dat, atât timp cât brokerul continuă să funcționeze.

    Similaritatea cu serviciile web provine din faptul că între client și broker există o conexiune de tip punct-la-punct; brokerul de mesaje este invizibil din punct de vedere funcțional.

    Asemănarea cu o magistrală de servicii provine din faptul că brokerul oferă un serviciu cu valoare adăugată, deoarece stochează mesajele primite până când sunt disponibili destinatarii. Spre deosebire de o magistrală de servicii, care este mai robustă, un broker de mesaje deține doar informații minime, privind lucruri simple, cum ar fi destinațiile care pot dori să primească un anumit mesaj și ce au de făcut dacă destinația nu accesează mesajul în timp util.

    Stilul de comunicare prin intermediul unui broker este descris ca având o rețea simplă. Deoarece brokerii au informații minime și trebuie să cunoască doar punctele finale și ce au de făcut atunci când trebuie trimis sau primit un mesaj. Acest stil este denumit coregrafie (spre deosebire de organizarea mai inteligentă a unei magistrale de servicii).

    Diagrama pentru un broker de mesaje, descrierea de mai josFurnizorul de mesaje îi transmite brokerului mesajul său. Apoi, brokerul stochează mesajul până când consumatorii îl solicită sau îl pot primi. Furnizorul nu depinde de consumator.

Rolul streamingului în mesageria corporativă

Pentru această discuție, streamingul poate fi văzut ca o formă de mesagerie mai degrabă specializată, deși unele tehnologii de streaming pot accepta un element de prelucrare a datelor. Streamingul, în acest context, descrie acțiunea de trimitere a unui flux continuu de evenimente prin intermediul tehnologiei IPC către aceleași destinații, indiferent dacă implementarea comunicărilor este sau nu asigurată de servicii web sau de brokerii de mesaje. (Magistralele de servicii sunt utilizate foarte rar, deoarece există prea multe date, care curg prea repede, pentru a fi necesare informațiile suplimentare ale unei magistrale de servicii.)

Pe lângă transmiterea continuă de date într-un flux, streamingul presupune, de obicei, o conectivitate aproape în timp real sau cu o latență scăzută. Acest lucru nu va fi surprinzător dacă ne gândim la servicii precum Netflix, denumite în mod tradițional „de streaming video”. Cu siguranță nu doriți să vizionați un conținut video care se oprește până când sunt trimise noi fragmente de la furnizor sau transformă un broker de mesaje clipul video dintr-un format în altul.

Tehnologiile obișnuite pentru streamingul de servicii web sunt: WebSockets, fluxurile gRPC și abonamentele GraphQL. În cazul fluxurilor de mesaje transmise prin intermediul brokerilor (folosind tehnologii precum Kafka), puteți folosi uneori brokerul pentru a vizualiza o „bucată” din evenimentele transmise. Astfel, puteți colecta informații prețioase, inclusiv despre fluxul în sine – de unde și termenul de analiză de streaming.

Deși logica aplicată în analiza de streaming poate fi sofisticată, brokerul de mesaje nu poate lua decizii sau manipula mesajele; de aceea, brokerul poate fi ignorat. Capacitățile pentru aceste analize de streaming sunt implementate adesea cu tehnologii precum Kafka Streams.

Standarde din domeniul API-urilor și mesageriei

API-urile și sistemele de mesagerie sunt simplu de descris, dar foarte complexe în detalii și caracteristici tehnice. Pur și simplu, nu este loc pentru ambiguitate, ceea ce duce la o nevoie reală de standarde și documente exacte în domeniu și, ideal, de aplicarea optimă a standardelor respective.

Acesta reprezintă un domeniu de dezvoltare, în special pentru API-uri, de peste zece ani. Domeniul a adoptat specificațiile OpenAPI pentru API-urile bazate pe REST, care sunt o formă de servicii web – și, probabil, cele mai comune tipuri de API-uri utilizate în software-ul corporativ modern.

Pentru API-uri (și streaming), există o serie de standarde suplimentare, care definesc și descriu aspectele mesajelor și ale transmiterii lor. Printre acestea, se numără bufferele de protocol (denumite și protobuf și utilizate cu gRPC) și, mai recent, GraphQL, JSON Schema și YAML.

În domeniul mesageriei asincrone, ca urmare a eforturilor din ultimii ani, s-a obținut o definiție, denumită AsyncAPI, care a adaptat idei de la OpenAPI și alte standarde în evoluție, pentru a răspunde numeroaselor cerințe legate de mesagerie.

Aplicațiile distribuite moderne sunt implementate ca o colecție de servicii care sunt componente software separate și pot sau nu să ruleze pe aceleași servere. API-urile oferă o modalitate prin care aceste componente software pot comunica între ele pentru a solicita servicii sau pentru a face schimb de informații. Sistemele de mesagerie oferă infrastructura care facilitează comunicările asincrone și intermediari inteligenți pentru apelurile API, care pot fi foarte simple (la fel cum funcționează mesajele text pe telefon) sau extrem de complexe (cum ar fi organizarea pentru tranzacții de business complexe, în mai multe etape). Ca să nu mai vorbim de serviciile distribuite, care comunică direct unele cu altele, prin API-uri. Din fericire, tehnicile și standardele în continuă evoluție permit utilizarea API-urilor peste tot, de la apelarea bazelor de date până la streamingul media. Iar aceste standarde pentru API-uri și mesagerie continuă să evolueze și să avanseze, făcând tranziția la arhitecturile software distribuite moderne mai rapidă, mai ușoară și mai sigură.

Oracle Chatbot
Disconnected