Wil jy jou toepassing aan Facebook koppel sodat dit outomaties plasings kan genereer, of aan Instagram sodat jy foto's met sekere hutsmerke kan herpos?
Jy kan ook YouTube-video's op jou webwerf insluit. Toepassingsprogrammeringskoppelvlakke laat jou toe om al hierdie take en meer (API's) uit te voer.
Verskillende toepassings kan op 'n veilige en gestandaardiseerde wyse met mekaar "praat" danksy API's soos die Instagram API, Facebook API en YouTube API.
Met ander woorde, 'n program kan kenmerke of data van 'n ander stuk sagteware neem en dit gebruik om sy eie kenmerke of gebruikerservaring te verbeter. Maar hoe kan toepassings hierdie versoeke rig, dit verwerk en daarop reageer op 'n manier wat ander kan verstaan?
Dit hang af van hoe die API geskep is. Wanneer API-ontwerpe (toepassingsprogrammeringskoppelvlak) bespreek word, is dit gewoonlik om SOAP vs. REST te vergelyk, twee van die mees prominente API-paradigmas.
Sodra SOAP API's (Simple Object Access Protocol) die goue standaard geword het vir firmas soos Oracle, Sun en PayPal, was daar 'n jaar of wat later 'n gelyke en teenoorgestelde reaksie op REST API's van Google, Amazon en eBay.
In hierdie pos sal ons SOAP API's met REST API's vergelyk en kontrasteer sodat jy kan besluit watter die beste vir jou doeleindes is.
Ons sal begin deur die API te definieer.
Wat is API?
Toepassingsprogrammeringskoppelvlak word API genoem. API's is in wese 'n versameling metodes en funksies wat die ontwikkeling van toepassings moontlik maak. Hulle kry toegang tot die inligting en funksies van verskillende programme, dienste of bedryfstelsels.
Hulle dien as 'n soort middelman tussen verskeie sagtewarestelsels. Hulle maak "praat" tussen twee nie-verbonde programme moontlik.
Kom ons neem die voorbeeld van 'n aandelemakelaar wat aktief betrokke is by handel en die finansiële markte. 'N Versameling van outomatiese handel algoritmes kan gekoppel word aan die handelaar se gunsteling handel makelaar platform deur middel van 'n API. Dit stel jou, die handelaar, in staat om elektroniese transaksies uit te voer of intydse kwotasies en prysdata te sien.
Wat is RUS?
Ware "webdienste" API's sluit REST (Representational State Transfer) in. REST API's is gebou op URI's (Uniform Resource Identifiers, waarvan 'n URL 'n spesiale soort is), die HTTP-protokol en die ongelooflike blaaier-versoenbare JSON-dataformaat.
Die SOAP-protokol, soos ons reeds gesê het, kan moontlik ook gebruik word. REST API's kan maklik wees om te skep en te groei, maar dit kan ook enorm en moeilik wees - dit hang alles af van hoe hulle geskep, uitgebrei word en wat hulle bedoel is om te doen.
Hulpbronbeperkings, verminderde sekuriteitsvereistes, blaaierkliëntversoenbaarheid, ontdekbaarheid, datagesondheid en skaalbaarheid is 'n paar redes waarom jy 'n API wil ontwikkel om RUSTIG te wees - dinge wat eintlik van toepassing is op webdienste.
REST bied 'n meer liggewig opsie. SOAP was moeilik om te gebruik en lastig vir baie ontwikkelaars. Byvoorbeeld, die gebruik van SOAP met JavaScript vereis die skryf van baie kode om eenvoudige bewerkings te voltooi, aangesien die nodige XML-struktuur elke keer geskep moet word.
REST gebruik (gewoonlik) 'n eenvoudige URL in die plek van 'n XML-versoek. Alhoewel daar seldsame omstandighede is wanneer u meer besonderhede moet verskaf, gebruik die meerderheid RESTful webdienste slegs die URL-tegniek.
Die vier HTTP 1.1 werkwoorde GET, POST, PUT en DELETE kan deur REST gebruik word om bewerkings uit te voer. Anders as SOAP, hoef REST nie die antwoord in XML te wees nie.
REST-gebaseerde webdienste wat data in Command Separated Value (CSV), JavaScript Object Notation (JSON) en Really Simple Syndication (RSS) formate uitvoer, is beskikbaar (RSS).
Die doelwit is dat jy die resultate kan kry wat jy nodig het in 'n maklik-om-te-ontleed formaat binne die taal wat jy vir jou toepassing gebruik.
Kenmerke
- REST beklemtoon eenvoud bo alles, as gevolg van HTTP-protokolle.
- Die web is die beste geskik vir RUS. Dit is versoenbaar met blaaiers omdat JSON as die dataformaat gebruik word.
- REST is bekend vir sy uitstekende skaalbaarheid en spoed.
- Kliënt-bediener verbindings en argitekture word meer toeganklik gemaak deur REST API's. As dit RUSTIG is, word dit gebou met behulp van hierdie kliënt-bediener-model, met heen- en terugreise tussen die twee partye wat data-loonvragte deurgee.
- REST API's gebruik 'n eensame standaardkoppelvlak. Om te verseker dat alle toepassings eenvormig en deur dieselfde poort verbind, stroomlyn hoe toepassings met die API kommunikeer.
Wat is SEEP?
Sy eie protokol, genaamd SOAP (Simple Object Access Protocol), is 'n bietjie meer ingewikkeld as REST aangesien dit meer standaarde spesifiseer, insluitend dié wat verband hou met sekuriteit en boodskaplewering.
Hierdie inherente norme kom wel met 'n bietjie ekstra bokoste. Hulle kan egter 'n deurslaggewende faktor wees vir besighede wat meer uitgebreide sekuriteit-, transaksie- en ACID (Atomiciteit, Konsekwentheid, Isolasie, Duursaamheid) voldoeningsvermoë benodig.
Ter wille van hierdie vergelyking is dit belangrik om daarop te let dat baie van die voordele van SOAP nie dikwels op webdienstoepassings van toepassing is nie, wat hulle meer geskik maak vir ondernemingstipe scenario's.
Hoër grade van sekuriteit (soos wanneer a mobiele toepassing interaksie met 'n bank), boodskapprogramme wat betroubare kommunikasie vereis, interaksie met verouderde stelsels, of ACID-nakoming is 'n paar redes waarom jy 'n toepassing wil ontwerp wat 'n SOAP API gebruik.
Die boodskapfunksies wat SOAP bied, is geheel en al gebaseer op XML. Ouer internet-onversoenbare tegnologieë soos die Distributed Component Object Model (DCOM) en Common Object Request Broker Architecture is deur SOAP vervang toe dit die eerste keer deur Microsoft (CORBA) geskep is.
Die afhanklikheid van binêre kommunikasie veroorsaak dat hierdie stelsels misluk. Oor die internet funksioneer XML-boodskappe soos dié wat deur SOAP gebruik word beter.
Kenmerke
- Die sekuriteit van SOAP is aansienlik strenger. WS-Security is 'n ingeboude standaard wat SOAP addisionele sekuriteitsvermoëns op ondernemingsvlak bied, indien nodig, benewens SSL-ondersteuning.
- Suksesvolle/herprobeer redenering vir betroubare boodskapprestasie. Omdat REST 'n gestandaardiseerde boodskapmeganisme ontbreek, kan dit net weer probeer wanneer kommunikasie misluk. Selfs wanneer SOAP-tussenprodukte gebruik word, bied SOAP end-tot-end betroubaarheid as gevolg van sy ingeboude suksesvolle/herprobeer-logika.
- SOAP voldoen reeds aan ACID-standaarde. Deur te dikteer hoe transaksies met die databasis kan inwerk, verminder ACID-nakoming onreëlmatighede en verseker die konsekwentheid van 'n databasis. Omdat ACID versigtiger is as ander datakonsekwentheidsmodelle, word dit gereeld gebruik wanneer sensitiewe transaksies, hetsy finansieel of andersins, bestuur word.
- Dit is maklik vir programmeerders om te verstaan, aangesien SOAP 'n heeltemal XML-gebaseerde kommunikasie is.
- Die XML-boodskapprotokol is 'n toevoeging tot die HTTP-protokol.
- Kommunikasie van een rekenaar na 'n ander rekenaars kan via SOAP-boodskappe versprei word.
- Kliënt-bediener argitektuur kan ook geïmplementeer word. 'n SOAP-protokolboodskap kan deur die kliënt gebruik word om 'n afstandprosedure-oproep wat bedienerkant geleë is, te bel.
RUS Vs SEEP Verskille
1. argitektuur
'n API is bedoel om hoofsaaklik spesifieke komponente van die besigheidslogika van 'n toepassing op 'n bediener te wys. Terwyl REST van URI's vir dieselfde doel gebruik maak, gebruik SOAP 'n Dienskoppelvlak hiervoor.
REST API's word na die data geskep, terwyl SOAP API's ontwikkel word na die funksionaliteite wat die API illustreer. In vergelyking met SOAP, wat meer funksie-gedrewe is, is REST 'n meer data-gedrewe ontwerp.
2. caching
Data wat as kasbaar gemerk is, kan weer deur blaaiers gebruik word sonder dat hulle 'n nuwe versoek aan die bediener moet rig. Om tyd en moeite te bespaar is 'n voordeel hiervan.
Antwoorde sal nie op die HTTP-vlak gekas word nie, aangesien SOAP-navrae via POST-versoeke ingedien word, wat die HTTP-standaard as nie-idempotent beskou. As jy caching wil gebruik, moet jy steeds die nodige tegnieke bou, aangesien REST API's nie hierdie implementering insluit nie.
3. Hulpbronne en bandwydte
As gevolg van die koevert-styl loonvragoordrag wat deur SOAP gebruik word, is daar 'n beskeie toename in bokoste, wat ekstra bandwydte noodsaak. REST se liggewig aard is 'n voordeel in hierdie situasies omdat dit oor die algemeen vir webdienste gebruik word.
4. Sekuriteit
WS-sekuriteit, wat SOAP ondersteun en effens meer deeglik as SSL op vervoervlak is, is wenslik. Om sekuriteitsmaatreëls op ondernemingsvlak daarby in te sluit, pas ook perfek.
End-tot-end-enkripsie met SSL word ondersteun deur beide SOAP en REST, en REST kan HTTPS, die veilige variant van die HTTP-protokol, gebruik.
5. Hantering van loonvragte
Data wat deur die internet versend word, word na verwys as 'n loonvrag. 'n Loonvrag wat as "swaar" beskou word, benodig bykomende hulpbronne. In vergelyking met SOAP, wat XML gebruik, gebruik REST dikwels JSON en HTTP om die loonvrag te verminder.
'n Gespesialiseerde Kliëntbiblioteek met gegenereerde kode moet tipies deur die Kliënt gebruik word om toegang tot SOAP API's te verkry weens hul uiters streng kommunikasiekontrak.
As gevolg hiervan, SOAP bied 'n minder vlak van abstraksie as REST en is nouer verbind met die bediener.
Wanneer om REST te gebruik?
- Skep publieke API's: REST API's word verkies vir die bou van publieke webdienste omdat dit gesien word dat dit makliker is om te gebruik en aan te neem as SOAP API's. Boonop bied SOAP verskeie ingeboude sekuriteitsmaatreëls wat REST nie het nie, alhoewel hierdie eienskappe nie vereis word wanneer met oop data en dienste gewerk word nie.
- Die bou van mobiele toepassings: REST is perfek vir die bou van mobiele toepassings aangesien dit klein, effektief, staatloos en kasbaar is.
- Gebruik skaars bedienerhulpbronne en bandwydte: Alle versoeke aan 'n REST API moet staatloos wees, wat beteken dat elke interaksie apart is en elke versoek en antwoord bevat al die data wat nodig is om daardie interaksie te voltooi. Die bediener stoor nie rekords van vorige versoeke nie, aangesien dit elkeen as 'n nuwe versoek behandel. Gevolglik benodig die bediener baie minder geheue en werk dit vinniger omdat 'n versoek nie verdere optrede of die herwinning van historiese data noodsaak nie.
Wanneer om SOAP te gebruik?
- Die skep van private API's, veral vir groot besighede: SOAP is perfek vir korporatiewe toepassings aangesien dit datavloei in 'n gedesentraliseerde, verspreide omgewing moontlik maak en verskeie aanlyn sekuriteitskenmerke bevat.
- Gebruik 'n ander vervoerprotokol as HTTP as die onderliggende laag: SOAP is nie afhanklik van HTTP as die onderliggende laag nie. Afhangende van jou toepassing, kan jy SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) of 'n ander vervoerprotokol gebruik.
- Werk met statige bedrywighede: In teenstelling met versoeke na REST API's, is versoeke na SOAP API's stateful, wat beteken dat die bediener inligting oor die kliënt stoor en dit oor 'n ketting van versoeke of bewerkings gebruik. Selfs al gebruik dit meer bedienerbandwydte en hulpbronne, is dit van kardinale belang vir die uitvoering van roetine of gekoppelde aksies, soos bankoorplasings.
Gevolgtrekking
Die vergelyking tussen REST en SOAP API's maak dit duidelik dat REST verkieslik is bo SOAP. Tog is daar situasies waar SOAP API vereis word. In sekere gevalle word webdienste geskep deur REST en SOAP API's te kombineer.
Daarom sal die gebruiksgeval bepaal watter API-styl die beste sal werk.
Lewer Kommentaar