API: t yhdistävät sovelluksia selkeiden protokollien ja arkkitehtuurien avulla. API-arkkitehtuuri on sääntökehys ohjelmistorajapintojen luomiseksi. Säännöt määrittävät, kuinka palvelintoimintoja tarjotaan käyttäjille. Arkkitehtuurin tyyppi määrittää säännöt ja rakenteet, jotka hallitsevat API: ta.
API-arkkitehtuurityyppejä on monia erilaisia REST: stä RPC: hen. Niiden rakenteen ja koostumuksen oppiminen auttaa sinua valitsemaan sovelluksesi.
1. LEVÄTÄ
REST-sovellusliittymät ovat moderneja ja ovat suosituin kehittäjien käyttämä API-arkkitehtuuri. LEVÄTÄ (representational state transfer) on arkkitehtuuri, jota käytetään asiakas-palvelin-sovellusten suunnitteluun. Se ei ole protokolla tai standardi, joten voit toteuttaa sen eri tavoin. Tämä näkökohta lisää joustavuuttasi kehittäjänä.
REST mahdollistaa pääsyn pyydettyihin tietokantaan tallennettuihin tietoihin. Voit suorittaa CRUD: n ydintoiminnot REST API: lla. Kun asiakkaat pyytävät sisältöä RESTful API: n kautta, heidän on käytettävä oikeita otsikoita ja parametreja. Ylätunnisteet sisältävät hyödyllisiä metatietoja resurssin tunnistamiseksi, kuten tilakoodeja ja valtuutus.
HTTP: n kautta siirrettävät tiedot voivat olla JSON-, HTML-, XML- tai pelkkää tekstiä. JSON on REST-sovellusliittymien yleisimmin käytetty tiedostomuoto. JSON on kieliagnostinen ja ihmisten luettavissa.
2. SAIPPUA
Yksinkertainen objektin käyttöprotokolla (SOAP) on virallinen API-protokolla. World Wide Web Consortium (W3C) ylläpitää SOAP-protokollaa, joka on yksi varhaisimmista API-arkkitehtuureista. Sen muotoilu helpottaa viestintää eri kielillä ja alustoilla rakennettujen sovellusten välillä.
SOAP-muoto kuvaa sovellusliittymää WSDL-verkkopalvelun kuvauskielellä. Se on kirjoitettu laajalla merkintäkielellä (XML). Muoto asettaa sisäänrakennetut yhteensopivuusstandardit, jotka lisäävät turvallisuutta, johdonmukaisuutta, eristystä ja kestävyyttä. Nämä ominaisuudet varmistavat luotettavat tietokantatapahtumat, mikä tekee SOAPista paremman yrityksen kehittämiseen.
Kun käyttäjä pyytää sisältöä SOAP API: n kautta, se käy läpi standardikerroksen protokollat. Vastaus on XML-muodossa, jota ihmiset ja koneet voivat lukea. Kuten REST-sovellusliittymät, SOAP-sovellusliittymät eivät tallenna tietoja välimuistiin/tallentaa. Jos tarvitset tietoja myöhemmin, sinun on tehtävä uusi pyyntö.
SOAP tukee sekä tilallista että tilatonta tiedonvaihtoa.
3. GraphQL
GraphQL on kyselykieli API: lle. Se on palvelinpuolen ajonaika, joka suorittaa kyselyjä määritellyn tietojoukon perusteella. GraphQL: llä on erityisiä käyttötapauksia. Sen arkkitehtuurin avulla voit ilmoittaa tarvitsemasi tiedot.
Toisin kuin REST-arkkitehtuurissa, jossa HTTP käsittelee asiakkaan pyynnöt ja vastaukset, GraphQL pyytää tietoja kyselyillä. GraphQL-palvelu määrittää näiden tyyppien tyypit ja kentät ja tarjoaa sitten toiminnot kullekin kentälle ja tyypille.
Palvelu vastaanottaa GraphQL-kyselyt vahvistamaan ja suorittamaan. Ensin se tarkistaa kyselyn varmistaakseen, että se viittaa määritettyihin tyyppeihin ja määriteltyihin kenttiin. Sitten se suorittaa siihen liittyvät toiminnot tuottaakseen halutun tuloksen.
GraphQL sopii erinomaisesti tiettyihin käyttötapauksiin, kuten tietojen hakemiseen useista lähteistä. Voit myös ohjata tiedonhakua ja säädellä pienempien laitteiden kaistanleveyttä.
4. Apache Kafka
Apache Kafka on hajautettu alusta, joka tukee tapahtumien suoratoistoa. Tapahtuman suoratoisto on prosessi, jossa dataa kerätään reaaliajassa lähteistä. Lähteet voivat olla tietokantoja, palvelimia tai ohjelmistosovelluksia. Kafka-järjestelmä koostuu palvelimista ja asiakkaista. Viestintä tapahtuu TCP-verkkoprotokollan kautta.
Voit ottaa järjestelmän käyttöön laitteistoissa, virtuaalikoneissa ja säilöissä. Voit tehdä tämän paikan päällä ja pilviympäristöissä. Apache Kafka -järjestelmä kaappaa tiedot, käsittelee ja reagoi siihen reaaliajassa. Se voi myös reitittää tiedot haluttuun kohteeseen reaaliajassa. Kafka kerää ja tallentaa tiedot järjestelmään, jonka voit hakea myöhemmin käyttöä varten.
Kafka tukee jatkuvaa tiedonkulkua ja integrointia. Näin varmistetaan, että tiedot ovat oikeassa paikassa oikeaan aikaan. Tapahtumien suoratoisto voi koskea monia käyttötapauksia, joissa tarvitaan suoraa datastriimiä. Näitä ovat rahoituslaitokset, terveydenhuolto, hallitus, kuljetusteollisuus ja tietokoneohjelmistoyritykset.
5. AsyncAPI
AsyncAPI on avoimen lähdekoodin aloite, joka auttaa rakentamaan ja ylläpitämään tapahtumalähtöisiä arkkitehtuureja. Sen spesifikaatioissa on monia yhteistä OpenAPI-spesifikaatioiden kanssa. AsyncAPI on pohjimmiltaan mukautus ja parannus OpenAPI-spesifikaatioista muutamilla eroilla.
AsyncAPI-arkkitehtuuri yhdistää yhdistelmän REST-sovellusliittymiä ja tapahtumapohjaisia sovellusliittymiä. Sen kaaviot pyyntöjen ja vastausten käsittelyyn ovat samanlainen kuin tapahtumasovellusliittymien. AsyncAPI tarjoaa spesifikaatioita asynkronisten sovellusten kuvaamiseen ja dokumentointiin koneellisesti luettavassa muodossa muoto. Se tarjoaa myös työkaluja, kuten koodigeneraattoreita, joiden avulla käyttäjien on helpompi toteuttaa niitä.
AsyncAPI parantaa tapahtumapohjaisen arkkitehtuurin (EDA) nykyistä tilaa. Tavoitteena on helpottaa työskentelyä EDA: iden kanssa kuten REST API: iden kanssa. AsyncAPI-aloite tarjoaa dokumentaatiota ja koodia, jotka tukevat tapahtumien hallintaa. Suurin osa REST API: issa käytetyistä prosesseista koskee tapahtumaohjattuja/asynkronisia API: ita.
AsyncAPI-määrityksen käyttäminen tapahtumapohjaisten järjestelmien dokumentoimiseen on elintärkeää. Se hallitsee ja ylläpitää johdonmukaisuutta ja tehokkuutta tapahtumalähtöisten projektien parissa työskentelevien tiimien välillä.
6. Remote Procedure Call (RPC)
RPC on ohjelmistoviestintäprotokolla, joka mahdollistaa tiedonsiirron verkon eri ohjelmien välillä. Ohjelma voi esimerkiksi pyytää tietoja toiselta verkon tietokoneelta. Sen ei tarvitse noudattaa verkkoprotokollia. Voit käyttää RPC: tä kutsumaan prosesseja etäjärjestelmissä aivan kuten paikallisessa järjestelmässä.
RPC toimii asiakas-palvelin mallilla. Asiakasohjelma pyytää ja palvelinohjelma vastaa palvelulla. RPC: t toimivat synkronisesti. Kun ohjelma lähettää pyynnön, se pysyy keskeytettynä, kunnes se saa vastauksen palvelimelta.
RPC: t ovat parhaita hajautettuihin järjestelmiin. Ne sopivat parhaiten komentopohjaisiin järjestelmiin, ja niissä on kevyt hyötykuorma, joka lisää suorituskykyä.
Kuinka valita oikea API-arkkitehtuuri
Oikea API-arkkitehtuuri riippuu käyttötapauksestasi. Arkkitehtuuri määrittää menetelmän API: n kehittämiseen ja sen toimivuuden. API: n arkkitehtoninen suunnittelu määrittelee sen komponentit ja vuorovaikutukset.
Tee arkkitehtonisia päätöksiä ennen API: n suunnittelua ja kehittämistä. Määritä API: n tekniset vaatimukset, taso, elinkaarihallinta ja tietoturva. API-arkkitehtuurimallit sisältävät rakennekerroksia. Tasot ohjaavat kehitystä ja varmistavat, että luotu API palvelee aiottuun tarkoitukseen.