API: er kopplar samman applikationer genom tydliga protokoll och arkitekturer. En API-arkitektur är ett ramverk av regler för att skapa programvarugränssnitt. Reglerna bestämmer hur serverfunktionalitet ska tillhandahållas till användare. Typen av arkitektur bestämmer reglerna och strukturerna som styr API: t.
Det finns många olika typer av API-arkitektur, från REST till RPC. Att lära sig om deras struktur och sammansättning hjälper dig att välja en för din applikation.
1. RESTEN
REST API: er är moderna och är den mest populära API-arkitekturen som utvecklare använder. RESTEN (representational state transfer) är en arkitektur som används för att designa klient-serverapplikationer. Det är inte ett protokoll eller standard, så du kan implementera det på olika sätt. Denna aspekt ökar din flexibilitet som utvecklare.
REST tillåter åtkomst till de begärda data som lagras i en databas. Du kan utföra CRUDs kärnfunktioner med ett REST API. När klienter begär innehåll via ett RESTful API måste de använda rätt rubriker och parametrar. Rubriker innehåller användbar metadata för att identifiera en resurs, som statuskoder och auktorisering.
Informationen som överförs via HTTP kan vara i JSON, HTML, XML eller vanlig text. JSON är det vanligaste filformatet för REST API: er. JSON är språkagnostisk och läsbar för människor.
2. TVÅL
Enkelt objektåtkomstprotokoll (SOAP) är ett officiellt API-protokoll. World Wide Web Consortium (W3C) upprätthåller SOAP-protokollet, som är en av de tidigaste API-arkitekturerna. Dess design underlättar kommunikationen mellan applikationer byggda med olika språk och plattformar.
SOAP-formatet beskriver ett API som använder webbtjänstbeskrivningsspråket (WSDL). Det är skrivet i det omfattande märkningsspråket (XML). Formatet ålägger inbyggda efterlevnadsstandarder som ökar säkerhet, konsekvens, isolering och hållbarhet. Dessa egenskaper säkerställer tillförlitliga databastransaktioner vilket gör SOAP bättre för företagsutveckling.
När en användare begär innehåll via ett SOAP API går det igenom standardlagerprotokollen. Svaret är i XML-format, som människor och maskiner kan läsa. Precis som REST-API: er, cachelagrar/lagrar SOAP-API: er inte information. Om du behöver uppgifterna senare måste du göra en ny begäran.
SOAP stöder både tillståndsbestämda och tillståndslösa datautbyten.
3. GraphQL
GraphQL är ett frågespråk för ett API. Det är en körtid på serversidan som exekverar frågor baserat på en definierad uppsättning data. GraphQL har specifika användningsfall. Dess arkitektur låter dig deklarera den specifika information du behöver.
Till skillnad från i REST-arkitektur, där HTTP hanterar klientförfrågningar och svar, begär GraphQL data med frågor. En GraphQL-tjänst definierar typerna och fälten för dessa typer och tillhandahåller sedan funktioner för varje fält och typ.
Tjänsten tar emot GraphQL-frågor att validera och utföra. Först kontrollerar den en fråga för att säkerställa att den refererar till de definierade typerna och fälten. Sedan kör den tillhörande funktioner för att producera det önskade resultatet.
GraphQL är bra för vissa användningsfall som att hämta data från flera källor. Du kan också styra datahämtning och reglera bandbredden för mindre enheter.
4. Apache Kafka
Apache Kafka är en distribuerad plattform som stöder strömning av händelser. Händelseströmning är processen att fånga data i realtid från källor. Källorna kan vara databaser, servrar eller mjukvaruapplikationer. Kafka-systemet består av servrar och klienter. Kommunikation sker genom ett TCP-nätverksprotokoll.
Du kan distribuera systemet på hårdvara, virtuella maskiner och behållare. Du kan göra detta på plats och i molnmiljöer. Apache Kafka-systemet fångar data, bearbetar och reagerar på det i realtid. Den kan också dirigera data till en önskad destination i realtid. Kafka fångar och lagrar data i systemet som du kan hämta senare för användning.
Kafka stödjer ett kontinuerligt flöde och integration av data. Detta säkerställer att informationen är på rätt plats, vid rätt tidpunkt. Händelseströmning kan gälla många användningsfall som kräver livedataströmmar. Dessa inkluderar finansiella institutioner, hälso- och sjukvård, myndigheter, transportindustrin och mjukvaruföretag.
5. AsyncAPI
AsyncAPI är ett initiativ med öppen källkod som hjälper till att bygga och underhålla evenemangsdrivna arkitekturer. Dess specifikationer har många saker gemensamt med OpenAPI-specifikationerna. AsyncAPI är i huvudsak en anpassning från, och förbättring av, OpenAPI-specifikationer, med några skillnader.
AsyncAPI-arkitekturen sammanför en blandning av REST API: er och händelsedrivna API: er. Dess scheman för hantering av förfrågningar och svar är liknande händelse-API: er. AsyncAPI tillhandahåller specifikationer för att beskriva och dokumentera asynkrona applikationer i en maskinläsbar formatera. Det tillhandahåller också verktyg som kodgeneratorer för att göra det lättare för användare att implementera dem.
AsyncAPI förbättrar det aktuella tillståndet för händelsestyrd arkitektur (EDA). Målet är att göra det lättare att arbeta med EDA: er som det är med REST API: er. AsyncAPI-initiativet tillhandahåller dokumentation och kod som stödjer eventhantering. Majoriteten av processerna som används i REST API: er gäller händelsedrivna/asynkrona API: er.
Att använda AsyncAPI-specifikationen för att dokumentera händelsestyrda system är avgörande. Det styr och upprätthåller konsekvens och effektivitet i team som arbetar med händelsedrivna projekt.
6. Remote Procedure Call (RPC)
RPC är ett mjukvarukommunikationsprotokoll som tillåter kommunikation mellan olika program i ett nätverk. Till exempel kan ett program begära information från en annan dator i nätverket. Det behöver inte följa nätverksprotokoll. Du kan använda RPC för att anropa processer på fjärrsystem precis som på det lokala systemet.
RPC arbetar på klient-server-modellen. Klientprogrammet begär och serverprogrammet svarar med en tjänst. RPC: er fungerar på synkronisering. När ett program skickar en begäran förblir det avstängt tills det får ett svar från servern.
RPC: er är bäst för distribuerade system. De är bäst för kommandobaserade system och har lätta nyttolaster som ökar prestandan.
Hur man väljer rätt API-arkitektur
Rätt API-arkitektur beror på ditt användningsfall. Arkitekturen bestämmer metodiken för att utveckla API: t och hur det kommer att köras. Den arkitektoniska designen av API definierar dess komponenter och interaktioner.
Ta arkitektoniska beslut innan du designar och utvecklar API: et. Bestäm de tekniska kraven för API: t, nivån, livscykelhantering och säkerhet. API-arkitekturdesigner innehåller strukturella lager. Skikten styr utvecklingen och säkerställer att API: et som skapas tjänar sitt avsedda syfte.
