API-er kobler sammen applikasjoner gjennom klare protokoller og arkitekturer. En API-arkitektur er et rammeverk av regler for å lage programvaregrensesnitt. Reglene bestemmer hvordan serverfunksjonalitet skal tilbys brukere. Typen arkitektur bestemmer reglene og strukturene som styrer API.
Det finnes mange forskjellige typer API-arkitektur, fra REST til RPC. Å lære om deres struktur og sammensetning vil hjelpe deg å velge en for applikasjonen din.
1. HVILE
REST APIer er moderne og er den mest populære API-arkitekturen som utviklere bruker. HVILE (representational state transfer) er en arkitektur som brukes til å designe klient-server-applikasjoner. Det er ikke en protokoll eller standard, så du kan implementere den på forskjellige måter. Dette aspektet øker din fleksibilitet som utvikler.
REST gir tilgang til de forespurte dataene som er lagret i en database. Du kan utføre CRUD-kjernefunksjonene med en REST API. Når klienter ber om innhold via en RESTful API, må de bruke de riktige overskriftene og parameterne. Overskrifter inneholder nyttige metadata for å identifisere en ressurs, som statuskoder og autorisasjon.
Informasjonen som overføres via HTTP kan være i JSON, HTML, XML eller ren tekst. JSON er det mest brukte filformatet for REST APIer. JSON er språkagnostisk og lesbar av mennesker.
2. SÅPE
Enkel objekttilgangsprotokoll (SOAP) er en offisiell API-protokoll. World Wide Web Consortium (W3C) opprettholder SOAP-protokollen, som er en av de tidligste API-arkitekturene. Designet letter kommunikasjonen mellom applikasjoner bygget med forskjellige språk og plattformer.
SOAP-formatet beskriver et API som bruker webservice description language (WSDL). Den er skrevet i det omfattende markup language (XML). Formatet pålegger innebygde samsvarsstandarder som øker sikkerhet, konsistens, isolasjon og holdbarhet. Disse egenskapene sikrer pålitelige databasetransaksjoner som gjør SOAP bedre for bedriftsutvikling.
Når en bruker ber om innhold gjennom et SOAP API, går det gjennom standard lagprotokoller. Svaret er i XML-format, som mennesker og maskiner kan lese. I likhet med REST-API-er, lagrer ikke SOAP-API-er informasjon. Hvis du trenger dataene senere, må du gjøre en ny forespørsel.
SOAP støtter både stateful og stateless datautveksling.
3. GraphQL
GraphQL er et spørrespråk for et API. Det er en kjøretid på serversiden som utfører spørringer basert på et definert sett med data. GraphQL har spesifikke brukstilfeller. Dens arkitektur lar deg deklarere den spesifikke informasjonen du trenger.
I motsetning til i REST-arkitektur, hvor HTTP håndterer klientforespørsler og svar, ber GraphQL om data med spørringer. En GraphQL-tjeneste definerer typene og feltene for disse typene, og gir deretter funksjoner for hvert felt og type.
Tjenesten mottar GraphQL-spørringer å validere og utføre. Først sjekker den en spørring for å sikre at den refererer til de definerte typene og feltene som er definert. Deretter kjører den de tilknyttede funksjonene for å produsere ønsket resultat.
GraphQL er flott for visse brukstilfeller som å hente data fra flere kilder. Du kan også kontrollere datahenting og regulere båndbredden for mindre enheter.
4. Apache Kafka
Apache Kafka er en distribuert plattform som støtter hendelsesstrømming. Hendelsesstreaming er prosessen med å fange data i sanntid fra kilder. Kildene kan være databaser, servere eller programvareapplikasjoner. Kafka-systemet består av servere og klienter. Kommunikasjon skjer gjennom en TCP-nettverksprotokoll.
Du kan distribuere systemet på maskinvare, virtuelle maskiner og containere. Du kan gjøre dette på stedet og i skymiljøer. Apache Kafka-systemet fanger data, prosesser og reagerer på det i sanntid. Den kan også rute dataene til en foretrukket destinasjon i sanntid. Kafka fanger opp og lagrer data i systemet som du kan hente senere for bruk.
Kafka støtter en kontinuerlig flyt og integrering av data. Dette sikrer at informasjonen er på rett sted, til rett tid. Hendelsesstrømming kan gjelde mange brukstilfeller som trenger direkte datastrømmer. Disse inkluderer finansinstitusjoner, helsevesen, myndigheter, transportindustrien og dataprogramvareselskaper.
5. AsyncAPI
AsyncAPI er et åpen kildekode-initiativ som bidrar til å bygge og vedlikeholde hendelsesdrevne arkitekturer. Spesifikasjonene har mange ting til felles med OpenAPI-spesifikasjonene. AsyncAPI er i hovedsak en tilpasning fra, og forbedring av, OpenAPI-spesifikasjoner, med noen få forskjeller.
AsyncAPI-arkitekturen samler en blanding av REST APIer og hendelsesdrevne APIer. Dens skjemaer for håndtering av forespørsler og svar er ligner på hendelses-APIer. AsyncAPI gir spesifikasjoner for å beskrive og dokumentere asynkrone applikasjoner i en maskinlesbar format. Det gir også verktøy som kodegeneratorer for å gjøre det enklere for brukere å implementere dem.
AsyncAPI forbedrer den nåværende tilstanden til hendelsesdrevet arkitektur (EDA). Målet er å gjøre det lettere å jobbe med EDA-er slik det er med REST API-er. AsyncAPI-initiativet gir dokumentasjon og kode som støtter hendelseshåndtering. Flertallet av prosessene som brukes i REST APIer gjelder hendelsesdrevne/asynkrone APIer.
Det er viktig å bruke AsyncAPI-spesifikasjonen til å dokumentere hendelsesdrevne systemer. Den styrer og opprettholder konsistens og effektivitet på tvers av team som jobber med hendelsesdrevne prosjekter.
6. Remote Procedure Call (RPC)
RPC er en programvarekommunikasjonsprotokoll som tillater kommunikasjon mellom ulike programmer på et nettverk. For eksempel kan et program be om informasjon fra en annen datamaskin på nettverket. Den trenger ikke å følge nettverksprotokoller. Du kan bruke RPC til å kalle prosesser på eksterne systemer akkurat som på det lokale systemet.
RPC opererer på klient-server-modellen. Klientprogrammet ber om og serverprogrammet svarer med en tjeneste. RPC-er opererer på synkronisering. Når et program sender en forespørsel, forblir det suspendert til det mottar et svar fra serveren.
RPC-er er best for distribuerte systemer. De er best for kommandobaserte systemer og har lette nyttelaster som øker ytelsen.
Hvordan velge riktig API-arkitektur
Riktig API-arkitektur avhenger av din brukssituasjon. Arkitekturen bestemmer metodikken for å utvikle APIen og hvordan den skal kjøres. Den arkitektoniske utformingen av API definerer dens komponenter og interaksjoner.
Ta arkitektoniske beslutninger før du designer og utvikler API. Bestem de tekniske kravene til API, nivået, livssyklusadministrasjon og sikkerhet. API-arkitekturdesign inneholder strukturelle lag. Lagene styrer utviklingen og sikrer at API-en som er opprettet tjener det tiltenkte formålet.