Popularni stilovi API arhitekture

Kada procenjujete svoju postojeću API strategiju, možda će biti potrebno da ponovo razmotrite vaš osnovni stil dizajna API-ja. Da li je REST i dalje najbolji izbor? Da li je GraphQL i dalje dobar izbor ili je to bio samo trend?

Prema Postman-ovom izveštaju State of the API 2022, najpopularniji stilovi API arhitekture su:

• REST (89%)
• Webhooks (35%)
• SOAP (34%)
• GraphQL (28%)
• Websockets (26%)
• gRPC (11%)
• MQTT (9%)
• AMQP (8%)
• Server-Sent Events (6%)
• EDI (4%)
• EDA (3%)
• Ostalo (1%)

Imajući u vidu ovoj pregled, hajde da pogledamo koji su to najbolji stilovi API arhitekture koji vam možemo preporučiti za vaše projekte u 2023 godini.

Proćićermo kroz prednosti i mane različitih stilova API arhitekture, kako biste lakše odlučili koji stil da primenite za vaš sledeći projekat razvoja API-ja.

Zato evo najpopularnijih stilova API arhitekture za 2023. godinu.

REST

REST je jedan od prvih standarda za API-je i i dalje je jedan od najboljih. REST je takođe i najpopularniji stil, čineći ogromnih 89% svih API-ja.

REST je skraćenica od REpresentational State Transfer. To je standard koji korisnicima omogućava da vrše zahteve za API koristeći jednostavne HTTP komande. REST-ova serverless arhitektura omogućava lakše razdvajanje između korisnika i servera, što ga čini odličnim za apstrakciju. Takođe podržava širok spektar formata podataka, što ga čini fleksibilnim i skalabilnim.

Međutim, REST ima i svoje nedostatke. Na primer, vraća puno metapodataka, što može usporiti vreme odziva i nepotrebno povećati prenos podataka. Ovaj veliki format, zajedno sa problemima u vezi sa prekomernim ili nedovoljnim fetch-ovanjem podataka (overfetching i underfetching), jedan je od glavnih razloga zašto je Facebook 2012. godine razvio GraphQL.

Webhooks

Ponekad nam je potrebna interakcija sa podacima u realnom vremenu. Možda je najbolje da aplikacija automatski prima najnovija ažuriranja umesto da manuelno šalje upite API-ju.

Webhooks rešavaju ove situacije za vas.

Webhook se može koristiti za slanje podataka kod svakog novog događaja. Na primer, zamislite da ste postavili novu email listu i želite ažuriranje kad god dobijete novu prijavu. Webhook može prenositi te podatke, štedeći vam vreme, trud i energiju potrebnu za upit. Ovo takođe može sprečiti rasipanje nepotrebnih resursa prilikom poziva API-ja u situacijama kada se podaci nisu promenili.

Glavni nedostatak webhook-a je što nisu tako svestrani ili prilagodljivi kao kompletni API-ji. Možemo ih u neku ruku uporediti sa jednosmernim prenosnikom podataka. Kod njih nakon slanja, nema odgovora da li prijemnik radi, pa nećete nužno znati ako se preneseni podaci ne dostavljaju na odgovarajuće mesto. Webhook-ovi imaju mnoge korisne primene, ali je zbog malopre pomenute mane važno uključiti i monitoring kako biste na vreme bili obavešteni ako nešto krene po zlu.

SOAP

SOAP je XML-formatirana struktura standardizovana od strane W3C. U pitanju je najčešće korišćen format za web usluge i koristan za veliki broj različitih aplikacija. SOAP je takođe odličan za privatnost, omogućavajući enkriptovane poruke i integritet u svakoj transakciji.

Međutim, zbog svoje opsežne XML strukture, SOAP je ujedno i najveći format datoteke. Iz tog razloga SOAP je prikladan samo kada je dostupna velika propusnost. Takođe je vrlo rigidan, pa nije vrlo prilagodljiv, što ograničava mogućnost nekog šireg usvajanja od strane developerske zajednice.

GraphQL

Facebook-ov GraphQL ima mnoge prednosti. Njegova jednostavna struktura podataka slična JSON-u i laka je za razumevanje i korišćenje, čak i za manje iskusne developere. GraphQL je nezavisan od baze podataka, što znači da ga možete koristiti sa gotovo bilo kojom bazom podataka koju možete zamisliti.

To čini vaš API izuzetno skalabilnim i prenosivim. Ove karakteristike su ključne za široko usvajanje i konačni uspeh API-ja. GraphQL je takođe odličan za privatnost, jer izlaže samo određene funkcije, a ostatak podataka ostaje bezbedan. Takođe ima detaljne error logove, što je korisno za velike i nezgrapne API-je.

Sa druge strane, GraphQL nije najbolji izbor za kompleksne upite, jer previše ugnježdenih upita može dovesti do preopterećenja i gašenja sistema.

WebSockets

WebSockets su pravi izbor ukoliko želite prednosti koje nudi webhook, ali želite i dvosmernu komunikaciju. Kao i kod webhook-a i WebSocket-i omogućavaju prenos podataka u realnom vremenu. Takođe mogu primati podatke, što ih čini mnogo boljim izborom. WebSocket konekcije su takođe mnogo brže od HTTP konekcija, pa su odličan izbor ako vam je brzina konekcije važan faktor.

Ipak, WebSocket-i imaju i neke probleme, Za razliku od drugih stilova API arhitekture, oni su dosta rigidniji. Ako WebSocket prestane da radi, nema ravnoteže opterećenja ili mehanizma za ponovno povezivanje. Takođe, za razliku od HTTP-a ne podržavaju keširanje. Mnogi proxy serveri takođe ne podržavaju WebSocket-e. To znači da često uz Websocket-e morate imati i infrastrukturu za HTTP streaming, što usložnjava arhitekturu i povećava zahtev za resursima.

gRPC

Uprkos mnogim prednostima, REST nije najbrža ili najefikasnija API arhitektura koja postoji. Realno, gRPC je čak 7 puta brži. Takođe, gRPC takođe ima kompajler izvornog koda, što eliminiše potrebu za upotrebom third-party alata. Na osnovu HTTP 2, gRPC je takođe idealan za mikroservisna okruženja i koristan za streaming podataka.

Jedna stvar koju treba imati na umu je da gRPC koristi Protobuf format umesto JSON-a. Protobuf je lak i efikasan zbog kompresije podataka. Međutim, nije tako razumljiv za ljude. Takođe nije toliko rasprostranjen kao JSON, pa može biti potrebno postaviti transalator ako integrišete gRPC API-je u druga API okruženja. gRPC je takođe složeniji i teže ga je implementirati od drugih stilova API arhitekture. Ako tražite nešto što je brzo i jednostavno za postavljanje, bilo bi bolje izabrati drugi stil API arhitekture, kao na primer REST.

MQTT

MQTT je koristan stil API arhitekture za IoT aplikacije. Popularan je zbog svoje lakoće i niske potrošnje baterije. Takođe je poznat po preciznosti poruka.

Za razliku od drugih stilova API arhitekture, MQTT ne koristi HTTP za slanje ili primanje zahteva. Umesto toga, koristi TCP/IP i „publish-subscribe“ model. To znači da prijemniku treba MQTT posrednik (broker) da se integriše sa uređajem koji koristi MQTT, a koji deluje kao vrsta pošte za MQTT poruke.

Međutim, MQTT je ograničen u svojoj funkcionalnosti. Može slati i primati samo osnovne zahteve i tipove datoteka. Takođe nije interaktivan kao REST i nedostaju mu mogućnosti za komande POST, GET, DELETE ili PUT. Imajući to u vidu, MQTT je uglavnom prikladan za specifične IoT aplikacije. Takođe je pogodan za projekte koji će u produkciji raditi sa ograničenom konektivnošću ili niskom propusnošću.

AMQP (Advanced Messaging Queuing Protocol)

AMQP je API arhitektura dizajnirana za mikroservise. AMQP označava Advanced Messaging Queuing Protocol i namenjen je upotrebi kada su potrebne ogromne količine podataka ili slanje poruka.

AMQP je kombinacija nekoliko stilova API arhitekture koje smo već razmatrali. Na primer, koristi „publish-subscribe“ model kao MQTT. Upotreba signala na nivou žice omogućava kontinuirane tokove podataka, što ga čini sličnim webhook-ovima i WebSocket-ima. Takođe koristi TCP kao i MQTT. AMQP je posebno siguran jer koristi Quality of Service (QoS) protokol. Takođe je veoma sposoban za obradu asinhronih poruka, bez obzira na operativni sistem.

Međutim, AMQP ima svoje nedostatke. Na primer, nije kompatibilan unazad, što znači da ćete moći da se integrišete samo sa trenutnom verzijom. Takođe je složeniji od HTTP-a, i zahteva veću propusnost od MQTT-a.

Server-Sent Events

Server-Sent Events (SSE) su kao mešavina webhook-ova i WebSockets-a, ali sa mnogo manje ograničenja. Oni nude efikasnost i povezivost webhook-ova i WebSockets-a, ali takođe omogućavaju automatsko ponovno povezivanje za slučaj da nešto krene po zlu.

SSE koriste XHR za striming podataka preko HTTP-a, što ih čini praktičnim izborom za projekte koji zahtevaju podatke u realnom vremenu, kao što su aplikacije za vreme ili berzanske usluge. SSE su prilično jednostavne za postavljanje i upotrebu, a podržane su u većini glavnih pregledača jer se koriste već nekoliko godina. Međutim, ako ih određeni browser još uvek ne podržava, mogu se polifilovati pomoću JavaScript-a.

Nedostatak je što SSE nisu toliko rasprostranjene, pa nema toliko biblioteka na raspolaganju. Takođe podržavaju ograničen opseg podataka i samo prenose UTF-8. Browseri takođe mogu podržati najviše šest SSE-ova istovremeno. Na kraju, SSE su samo jednosmerne, pa je njihova upotreba ograničena i specifična, obično za aplikacije u realnom vremenu.

EDI/EDA

EDI označava Electronic Data Interchange, a EDA je skraćenica za event-driven architecture (arhitektura zasnovana na događajima). Obe pružaju moćne mogućnosti za prenos podataka na različite načine.

EDI postoji od kasnih 70-ih godina. Koristi P2P mrežu za prenos velike količine standardizovanih podataka. Prilično je jednostavan za upotrebu i široko rasprostranjen, zahvaljujući svojoj dugovečnosti. Kao i AMQP, EDI takođe nije kompatibilan unazad. Postoje tri verzije EDI-ja, i svaka radi samo sa istom verzijom.

EDI je takođe mnogo ograničeniji u svom opsegu i korisnosti. Više je kao tunel nego kao razmena, jer može povezati samo dva korisnika. Takođe je relativno skup i zahtevan za implementaciju.

EDA takođe postoji od 70-ih godina. To je prilično jednostavan koncept, sličan webhook-ovima na mnoge načine. Kada se nešto dogodi, pokreće se nešto drugo. EDA je inherentno skalabilna – događaji se mogu postaviti u red i dohvatiti kasnije. Pretplate se mogu uključiti i isključiti, što EDA čini korisnim za „objavi/pretplati“ aplikacije .

Uvek treba biti oprezan sa aplikacijama u realnom vremenu, budući da nemaju ugrađene zaštitne mehanizme. Ako je EDA povezana sa uslugom koja naplaćuje po transakciji, to može brzo postati skupo. Takođe može izazvati probleme sa performansama, u zavisnosti od količine saobraćaja u određenom trenutku.

Zaključak

Prilikom izbora odgovarajućeg stila API arhitekture, imajte pre svega u vidu specifične prednosti i mane svakog od navedenih stilova.

REST, kao najpopularniji od njih, pruža fleksibilnost, skalabilnost i podršku za širok spektar formata podataka. Međutim, može biti spor zbog metapodataka i ima probleme sa overfetching-om i underfetching-om.

• Webhooks omogućavaju real-time interakciju sa podacima, ali su manje prilagodljivi od kompletnih API-ja.
• SOAP je dobar izbor za privatnost i integritet podataka, ali je veličinom datoteke ograničen i manje fleksibilan.
• GraphQL je jednostavan za korišćenje i nezavisan od baze podataka, što ga čini skalabilnim, ali nije najbolji za kompleksne upite.
• Websockets omogućavaju dvosmernu komunikaciju u realnom vremenu, ali mogu imati problema sa ravnotežom opterećenja i podrškom za proxy servere.
• gRPC je brži od REST-a, ali je kompleksniji za implementaciju i nije tako rasprostranjen.
• MQTT je pogodan za IoT aplikacije, ali nije interaktivan kao REST i ograničen je u funkcionalnostima.
• AMQP kombinuje više stilova API arhitekture, ali zahteva veću propusnost i složeniji je od HTTP-a.
• Server-Sent Events kombinuju efikasnost webhook-ova i povezivost WebSockets-a, ali imaju ograničen opseg i nisu tako rasprostranjeni.
• EDI i EDA pružaju moćne mogućnosti za prenos podataka, ali EDI nije kompatibilan unazad, a EDA zahteva specifičnu implementaciju.

Na kraju, u konačnom izboru stilova API arhitekture za vaše projekte u 2023. godini, treba uzeti u obzir specifične potrebe konkretnog projekta i uzeti u obzir prednosti i mane svakog stila.