Vill du länka din app till Facebook så att den kan generera inlägg automatiskt, eller till Instagram så att du kan lägga upp bilder med vissa hashtags?
Du kan också vilja inkludera YouTube-videor på din webbplats. Med gränssnitt för applikationsprogrammering kan du utföra alla dessa uppgifter och mer (API).
Olika applikationer kan "tala" med varandra på ett säkert och standardiserat sätt tack vare API:er som Instagram API, Facebook API och YouTube API.
Med andra ord kan ett program ta funktioner eller data från en annan mjukvara och använda dem för att förbättra sina egna funktioner eller användarupplevelse. Men hur kan appar göra dessa förfrågningar, bearbeta dem och svara på dem på ett sätt som andra kan förstå?
Det beror på hur API skapades. När man diskuterar API-design (applikationsprogrammeringsgränssnitt) är det vanligt att jämföra SOAP vs. REST, två av de mest framträdande API-paradigmen.
Så snart SOAP API:er (Simple Object Access Protocol) blev guldstandarden för företag som Oracle, Sun och PayPal, var det ett lika och motsatt svar något år senare mot REST API:er från Google, Amazon och eBay.
I det här inlägget kommer vi att jämföra och kontrastera SOAP API:er med REST API:er så att du kan bestämma vilken som är bäst för dina syften.
Vi börjar med att definiera API:t.
Vad är API?
Application Programming Interface kallas API. API:er är i huvudsak en samling metoder och funktioner som möjliggör utveckling av appar. De får tillgång till information och funktioner för olika program, tjänster eller operativsystem.
De fungerar som ett slags mellanhand mellan olika mjukvarusystem. De gör det möjligt att "prata" mellan två oanslutna program.
Låt oss ta exemplet med en aktiemäklare som är aktivt involverad i handel och finansmarknader. En samling av automatiserade handelsalgoritmer kan kopplas till handlarens favorithandelsmäklarplattform genom ett API. Detta gör det möjligt för dig som handlare att utföra elektroniska transaktioner eller se offerter och prisuppgifter i realtid.
Vad är REST?
Verkliga API:er för "webbtjänster" inkluderar REST (Representational State Transfer). REST API:er är byggda på URI:er (Uniform Resource Identifiers, varav en URL är en speciell typ), HTTP-protokollet och det otroligt webbläsarkompatibla JSON-dataformatet.
SOAP-protokollet, som vi redan nämnt, kan möjligen också användas. REST API:er kan vara lätta att skapa och växa, men de kan också vara enorma och svåra – allt beror på hur de skapas, utökas och vad de är avsedda att göra.
Resursbegränsningar, minskade säkerhetskrav, webbläsarklientkompatibilitet, upptäckbarhet, datahälsa och skalbarhet är några anledningar till att du skulle vilja utveckla ett API för att vara RESTful – saker som faktiskt gäller webbtjänster.
REST erbjuder ett mer lättviktigt alternativ. SOAP var svår att använda och betungande för många utvecklare. Att använda SOAP med JavaScript kräver till exempel att man skriver mycket kod för att slutföra enkla operationer eftersom den nödvändiga XML-strukturen måste skapas varje gång.
REST använder (vanligtvis) en enkel URL i stället för en XML-förfrågan. Även om det finns sällsynta omständigheter när du måste erbjuda mer information, använder majoriteten av RESTful webbtjänster endast URL-tekniken.
De fyra HTTP 1.1-verben GET, POST, PUT och DELETE kan användas av REST för att utföra operationer. Till skillnad från SOAP behöver REST inte svaret vara i XML.
REST-baserade webbtjänster som matar ut data i formaten Command Separated Value (CSV), JavaScript Object Notation (JSON) och Really Simple Syndication (RSS) är tillgängliga (RSS).
Målet är att du kan få de resultat du behöver i ett lätttolkat format inom det språk du använder för din applikation.
Funktioner
- REST betonar enkelhet framför allt, tack vare HTTP-protokoll.
- Webben lämpar sig bäst för REST. Det är kompatibelt med webbläsare eftersom JSON används som dataformat.
- REST är känt för sin enastående skalbarhet och hastighet.
- Klient-serveranslutningar och arkitekturer görs mer tillgängliga av REST API:er. Om det är RESTful, är det konstruerat med hjälp av denna klient-server-modell, med rundresor mellan de två parterna som passerar datanyttolaster.
- REST API:er använder ett ensamt standardgränssnitt. Säkerställer att alla appar ansluter enhetligt och via samma gateway, effektiviserar hur appar kommunicerar med API.
Vad är SOAP?
Dess eget protokoll, kallat SOAP (Simple Object Access Protocol), är lite mer komplicerat än REST eftersom det specificerar fler standarder, inklusive de som är relaterade till säkerhet och meddelandeleverans.
Dessa inneboende normer kommer med lite extra omkostnader. De kan dock vara en avgörande faktor för företag som behöver mer omfattande säkerhets-, transaktions- och ACID (Atomicity, Consistency, Isolation, Durability) efterlevnadskapacitet.
För denna jämförelses skull är det viktigt att notera att många av fördelarna med SOAP inte ofta gäller webbtjänstapplikationer, vilket gör dem mer lämpade för företagsscenarier.
Högre grader av säkerhet (som när en mobil app interagerar med en bank), meddelandeappar som kräver pålitlig kommunikation, interaktion med äldre system eller ACID-efterlevnad är några anledningar till att du skulle vilja designa en applikation som använder ett SOAP API.
De meddelandefunktioner som SOAP erbjuder är helt baserade på XML. Äldre internet-inkompatibla tekniker som Distributed Component Object Model (DCOM) och Common Object Request Broker Architecture ersattes av SOAP när den först skapades av Microsoft (CORBA).
Beroendet på binär kommunikation gör att dessa system misslyckas. Över internet fungerar XML-meddelanden som den som används av SOAP bättre.
Funktioner
- Säkerheten för SOAP är betydligt stramare. WS-Security är en inbyggd standard som erbjuder SOAP ytterligare säkerhetsfunktioner på företagsnivå vid behov utöver SSL-stöd.
- Resonemang för pålitlig meddelandeprestanda lyckades/försök igen. Eftersom REST saknar en standardiserad meddelandemekanism kan den bara försöka igen när kommunikationen misslyckas. Även när man använder SOAP-mellanprodukter erbjuder SOAP end-to-end-pålitlighet tack vare sin inbyggda logik för framgångsrikt/försök igen.
- SOAP uppfyller redan ACID-standarder. Genom att diktera hur transaktioner kan interagera med databasen, minimerar ACID-efterlevnad avvikelser och säkerställer konsistensen i en databas. Eftersom ACID är mer försiktig än andra datakonsistensmodeller, används den ofta vid hantering av känsliga transaktioner, vare sig de är finansiella eller på annat sätt.
- Det är enkelt för programmerare att förstå eftersom SOAP är en helt XML-baserad kommunikation.
- XML-meddelandeprotokollet är ett tillägg till HTTP-protokollet.
- Kommunikation från en dator till en annan dator kan spridas via SOAP-meddelanden.
- Klient-server-arkitektur kan också implementeras. Ett SOAP-protokollmeddelande kan användas av klienten för att anropa ett fjärrproceduranrop som är beläget på serversidan.
Skillnader mellan vila och tvål
1. arkitektur
Ett API är avsett att i första hand visa specifika komponenter i affärslogiken för en applikation på en server. Medan REST använder URI:er för samma ändamål, använder SOAP ett tjänstegränssnitt för detta.
REST API: er skapas efter data, medan SOAP API: er utvecklas efter de funktioner som API illustrerar. Jämfört med SOAP, som är mer funktionsdriven, är REST en mer datadriven design.
2. caching
Data som har markerats som cachebart kan användas av webbläsare igen utan att de behöver göra en ny begäran till servern. Att spara tid och ansträngning är en fördel med detta.
Svar kommer inte att cachelagras på HTTP-nivå eftersom SOAP-frågor skickas via POST-förfrågningar, som HTTP-standarden anser vara icke-idempotenta. Om du vill använda cachning måste du fortfarande bygga de nödvändiga teknikerna eftersom REST API:er inte inkluderar denna implementering.
3. Resurser & bandbredd
På grund av den kuvertliknande nyttolastöverföringen som används av SOAP, finns det en blygsam ökning av omkostnader, vilket kräver extra bandbredd. REST:s lätta karaktär är en fördel i dessa situationer eftersom den vanligtvis används för webbtjänster.
4. Säkerhet
WS-säkerhet, som SOAP stödjer och är något mer noggrann än SSL på transportnivå, är önskvärt. Att införliva säkerhetsåtgärder på företagsnivå är också en perfekt passform.
End-to-end-kryptering med SSL stöds av både SOAP och REST, och REST kan använda HTTPS, den säkra varianten av HTTP-protokollet.
5. Hantering av nyttolaster
Data som överförs via Internet kallas nyttolast. En nyttolast som anses vara "tung" behöver ytterligare resurser. Jämfört med SOAP, som använder XML, använder REST ofta JSON och HTTP för att hjälpa till att minska nyttolasten.
Ett specialiserat klientbibliotek med genererad kod måste vanligtvis användas av klienten för att komma åt SOAP API:er på grund av deras extremt stränga kommunikationskontrakt.
Som ett resultat erbjuder SOAP en lägre abstraktionsnivå än REST och är närmare ansluten till servern.
När ska man använda REST?
- Skapa offentliga API:er: REST API:er är att föredra för att bygga offentliga webbtjänster eftersom de anses vara enklare att använda och använda än SOAP API:er. Dessutom erbjuder SOAP flera inbyggda säkerhetsåtgärder som REST inte har, även om dessa egenskaper inte krävs när man arbetar med öppna data och tjänster.
- Bygger mobilappar: REST är perfekt för att bygga mobila applikationer eftersom det är litet, effektivt, tillståndslöst och cachebart.
- Använder knappa serverresurser och bandbredd: Alla förfrågningar till ett REST API måste vara tillståndslösa, vilket innebär att varje interaktion är separat och varje begäran och svar innehåller all data som behövs för att slutföra den interaktionen. Servern sparar inte register över tidigare förfrågningar eftersom den behandlar var och en som en ny begäran. Som ett resultat kräver servern mycket mindre minne och fungerar snabbare eftersom en begäran inte kräver ytterligare åtgärder eller hämtning av historisk data.
När ska man använda SOAP?
- Skapa privata API:er, särskilt för stora företag: SOAP är perfekt för företagsapplikationer eftersom det möjliggör dataflöde i en decentraliserad, distribuerad miljö och innehåller flera säkerhetsfunktioner online.
- Använder ett annat transportprotokoll än HTTP som underliggande lager: SOAP är inte beroende av HTTP som underliggande lager. Beroende på din applikation kan du använda SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) eller ett annat transportprotokoll.
- Arbetar med statlig verksamhet: Till skillnad från förfrågningar till REST-API:er är förfrågningar till SOAP-API:er tillståndsbestämda, vilket innebär att servern sparar information om klienten och använder den över en kedja av förfrågningar eller operationer. Även om detta använder mer serverbandbredd och resurser, är det avgörande för att utföra rutinmässiga eller länkade åtgärder, som banköverföringar.
Slutsats
Jämförelsen mellan REST och SOAP API:er gör det ganska uppenbart att REST är att föredra framför SOAP. Ändå finns det situationer där SOAP API krävs. I vissa fall skapas webbtjänster genom att kombinera REST och SOAP API:er.
Därför kommer användningsfallet att avgöra vilken API-stil som fungerar bäst.
Kommentera uppropet