Ydych chi eisiau cysylltu'ch app â Facebook fel y gall gynhyrchu postiadau yn awtomatig, neu i Instagram fel y gallwch chi ail-bostio lluniau gyda rhai hashnodau?
Gallech hefyd ddymuno cynnwys fideos YouTube ar eich gwefan. Mae rhyngwynebau rhaglennu cymwysiadau yn caniatáu ichi gyflawni'r holl dasgau hyn a mwy (API).
Gall gwahanol gymwysiadau “siarad” â'i gilydd mewn modd diogel a safonol diolch i APIs fel Instagram API, Facebook API, ac YouTube API.
Mewn geiriau eraill, gall rhaglen gymryd nodweddion neu ddata o ddarn arall o feddalwedd a'u defnyddio i wella ei nodweddion ei hun neu brofiad y defnyddiwr. Ond sut y gall apiau wneud y ceisiadau hyn, eu prosesu, ac ymateb iddynt mewn modd y gall eraill ei ddeall?
Mae hynny'n dibynnu ar sut y crëwyd yr API. Wrth drafod dyluniadau API (rhyngwyneb rhaglennu cymhwysiad), mae'n arferol cymharu SOAP vs. REST, dau o'r paradeimau API amlycaf.
Cyn gynted ag y daeth APIs SEBON (Protocol Mynediad Gwrthrych Syml) yn safon aur ar gyfer cwmnïau fel Oracle, Sun, a PayPal, cafwyd ymateb cyfartal a chyferbyniol tua blwyddyn yn ddiweddarach tuag at APIs REST gan Google, Amazon, ac eBay.
Yn y swydd hon, byddwn yn cymharu ac yn cyferbynnu APIs SEBON ag APIs REST er mwyn i chi allu penderfynu pa un sydd orau at eich dibenion chi.
Byddwn yn dechrau trwy ddiffinio'r API.
Beth yw API?
Cyfeirir at Ryngwyneb Rhaglennu Cymwysiadau fel API. Mae APIs yn eu hanfod yn gasgliad o ddulliau a swyddogaethau sy'n galluogi datblygu apiau. Maent yn cael mynediad at y wybodaeth a swyddogaethau gwahanol raglenni, gwasanaethau, neu systemau gweithredu.
Maent yn gwasanaethu fel rhyw fath o ddyn canol rhwng systemau meddalwedd amrywiol. Maent yn galluogi “siarad” rhwng dwy raglen heb gysylltiad.
Gadewch i ni gymryd yr enghraifft o frocer stoc sy'n cymryd rhan weithredol mewn masnachu a'r marchnadoedd ariannol. Casgliad o awtomataidd algorithmau masnachu gellir ei gysylltu â llwyfan brocer masnachu hoff y masnachwr trwy API. Mae hyn yn eich galluogi chi, y masnachwr, i gyflawni trafodion electronig neu weld dyfynbrisiau amser real a data prisio.
Beth yw REST?
Mae APIs “gwasanaethau gwe” go iawn yn cynnwys REST (Trosglwyddo Talaith Cynrychioliadol). Mae APIs REST wedi'u hadeiladu ar URIs (Dynodwyr Adnoddau Unffurf, y mae URL yn fath arbennig ohonynt), y protocol HTTP, a'r fformat data JSON sy'n hynod gydnaws â porwr.
Mae'n bosibl y bydd y protocol SEBON, fel y dywedasom eisoes, o bosibl yn cael ei ddefnyddio hefyd. Gall APIs REST fod yn hawdd i'w creu a'u tyfu, ond gallant hefyd fod yn enfawr ac yn anodd - mae'r cyfan yn dibynnu ar sut y cânt eu creu, eu hehangu, a'r hyn y bwriedir iddynt ei wneud.
Mae cyfyngiadau adnoddau, llai o ofynion diogelwch, cydnawsedd cleient porwr, darganfodadwyedd, iechyd data, a scalability yn rhai rhesymau yr hoffech chi ddatblygu API i fod yn RESTful - pethau sy'n berthnasol mewn gwirionedd i wasanaethau gwe.
Mae REST yn cynnig opsiwn mwy ysgafn. Roedd SEBON yn anodd ei ddefnyddio ac yn feichus i lawer o ddatblygwyr. Er enghraifft, mae defnyddio SEBON gyda JavaScript yn gofyn am ysgrifennu llawer o god i gwblhau gweithrediadau syml gan fod yn rhaid creu'r strwythur XML angenrheidiol bob tro.
Mae REST (fel arfer) yn defnyddio URL syml yn lle cais XML. Er bod yna amgylchiadau prin pan fydd yn rhaid i chi gynnig mwy o fanylion, dim ond y dechneg URL y mae mwyafrif gwasanaethau gwe RESTful yn ei defnyddio.
Gall REST ddefnyddio'r pedair berf HTTP 1.1 GET, POST, PUT, a DELETE i gyflawni gweithrediadau. Yn wahanol i SOAP, nid oes angen yr ateb ar REST i fod yn XML.
Mae gwasanaethau gwe seiliedig ar REST sy'n allbynnu data mewn fformatau Command Separated Value (CSV), JavaScript Object Notation (JSON), a Really Simple Syndication (RSS) ar gael (RSS).
Y nod yw y gallwch chi gael y canlyniadau sydd eu hangen arnoch chi mewn fformat hawdd ei ddosrannu o fewn yr iaith rydych chi'n ei defnyddio ar gyfer eich cais.
Nodweddion
- Mae REST yn pwysleisio symlrwydd yn anad dim arall, oherwydd protocolau HTTP.
- Y we sydd fwyaf addas ar gyfer REST. Mae'n gydnaws â phorwyr oherwydd defnyddir JSON fel y fformat data.
- Mae REST yn enwog am ei scalability a chyflymder rhagorol.
- Mae cysylltiadau a phensaernïaeth cleient-gweinydd yn fwy hygyrch gan REST APIs. Os yw'n RESTful, caiff ei adeiladu gan ddefnyddio'r model cleient-gweinyddwr hwn, gyda theithiau crwn rhwng y ddau barti yn pasio llwythi tâl data.
- Mae REST APIs yn defnyddio rhyngwyneb safonol unigol. Mae sicrhau bod pob ap yn cysylltu'n unffurf a thrwy'r un porth yn symleiddio sut mae cymwysiadau'n cyfathrebu â'r API.
Beth yw SEBON?
Mae ei brotocol ei hun, o'r enw SOAP (Protocol Mynediad Gwrthrych Syml), ychydig yn fwy cymhleth na REST gan ei fod yn nodi mwy o safonau, gan gynnwys y rhai sy'n ymwneud â diogelwch a chyflwyno negeseuon.
Mae'r normau cynhenid hyn yn dod ag ychydig bach ychwanegol uwchben. Fodd bynnag, gallant fod yn ffactor tyngedfennol i fusnesau sydd angen galluoedd cydymffurfio mwy helaeth o ran diogelwch, trafodion, ac ACID (Atomity, Cysondeb, Ynysu, Gwydnwch).
Er mwyn y gymhariaeth hon, mae'n bwysig nodi nad yw llawer o fanteision SEBON yn berthnasol i gymwysiadau gwasanaethau gwe yn aml, gan eu gwneud yn fwy addas ar gyfer senarios tebyg i fenter.
Lefelau uwch o ddiogelwch (fel pan a app symudol yn rhyngweithio â banc), mae apiau negeseuon sydd angen cyfathrebu dibynadwy, rhyngweithio â systemau etifeddiaeth, neu gydymffurfiaeth ACID yn ychydig o resymau yr hoffech chi ddylunio cymhwysiad gan ddefnyddio API SEBON.
Mae'r galluoedd negeseuon a gynigir gan SOAP yn gwbl seiliedig ar XML. Disodlwyd technolegau hŷn sy'n anghydnaws â'r rhyngrwyd fel y Model Gwrthrych Cydran Dosbarthedig (DCOM) a Phensaernïaeth Brocer Cais Gwrthrych Cyffredin gan SOAP pan gafodd ei greu gyntaf gan Microsoft (CORBA).
Mae'r ddibyniaeth ar gyfathrebiadau deuaidd yn achosi i'r systemau hyn fethu. Dros y rhyngrwyd, mae negeseuon XML fel yr un a ddefnyddir gan SEBON yn gweithio'n well.
Nodweddion
- Mae diogelwch SEBON yn sylweddol dynnach. Mae WS-Security yn safon adeiledig sy'n cynnig galluoedd diogelwch ychwanegol ar lefel menter SEBON os oes angen yn ogystal â chymorth SSL.
- Llwyddiannus/ailgeisio rhesymu dros berfformiad negeseuon dibynadwy. Oherwydd nad oes gan REST fecanwaith negeseuon safonol, dim ond pan fydd cyfathrebu'n methu y gall ailgynnig. Hyd yn oed wrth ddefnyddio canolradd SEBON, mae SOAP yn cynnig dibynadwyedd o'r dechrau i'r diwedd oherwydd ei resymeg lwyddiannus / ailgynnig integredig.
- Mae SEBON eisoes yn cydymffurfio â safonau ASID. Trwy bennu sut y gall trafodion ryngweithio â'r gronfa ddata, mae cydymffurfiaeth ACID yn lleihau anghysondebau ac yn diogelu cysondeb cronfa ddata. Gan fod ACID yn fwy gofalus na modelau cysondeb data eraill, fe'i defnyddir yn aml wrth reoli trafodion sensitif, boed yn ariannol neu fel arall.
- Mae'n syml i raglenwyr ddeall gan fod SOAP yn gyfathrebiad cwbl seiliedig ar XML.
- Mae protocol negeseuon XML yn ychwanegiad at y protocol HTTP.
- Gellir lledaenu cyfathrebiadau o un cyfrifiadur i gyfrifiadur arall trwy negeseuon SEBON.
- Gellir gweithredu pensaernïaeth cleient-gweinydd hefyd. Gall y cleient ddefnyddio neges protocol SEBON i alw galwad gweithdrefn o bell sydd wedi'i lleoli ar ochr y gweinydd.
REST Vs Gwahaniaethau SEBON
1. Pensaernïaeth
Bwriad API yw dangos yn bennaf elfennau penodol o resymeg busnes cymhwysiad ar weinydd. Er bod REST yn defnyddio URIs at yr un diben, mae SOAP yn defnyddio Rhyngwyneb Gwasanaeth ar gyfer hyn.
Mae REST APIs yn cael eu creu ar ôl y data, tra bod API SEBON yn cael eu datblygu ar ôl y swyddogaethau y mae'r API yn eu dangos. O'i gymharu â SOAP, sy'n cael ei yrru'n fwy gan swyddogaethau, mae REST yn ddyluniad sy'n cael ei yrru'n fwy gan ddata.
2. Caching
Gall porwyr ddefnyddio data sydd wedi'i nodi fel storfa y gellir ei storio eto heb fod angen iddynt wneud cais newydd i'r gweinydd. Mae arbed amser ac ymdrech yn fantais i hyn.
Ni fydd ymatebion yn cael eu storio ar lefel HTTP gan fod ymholiadau SEBON yn cael eu cyflwyno trwy geisiadau POST, y mae safon HTTP yn ei hystyried yn amherthnasol. Os ydych chi am gyflogi caching, mae'n rhaid i chi adeiladu'r technegau angenrheidiol o hyd gan nad yw APIs REST yn cynnwys y gweithrediad hwn.
3. Adnoddau a Lled Band
Oherwydd y trosglwyddiad llwyth tâl ar ffurf amlen a ddefnyddir gan SOAP, mae cynnydd bach yn y gorbenion, sy'n golygu bod angen lled band ychwanegol. Mae natur ysgafn REST yn fantais yn y sefyllfaoedd hyn oherwydd fe'i defnyddir yn gyffredinol ar gyfer gwasanaethau gwe.
4. Diogelwch
Mae WS-security, y mae SEBON yn ei gefnogi ac sydd ychydig yn fwy trylwyr na SSL ar lefel trafnidiaeth, yn ddymunol. Mae ymgorffori mesurau diogelwch lefel menter gydag ef hefyd yn ffit perffaith.
Cefnogir amgryptio o un pen i'r llall gan ddefnyddio SSL gan SOAP a REST, a gall REST ddefnyddio HTTPS, yr amrywiad diogel o'r protocol HTTP.
5. Trin Llwythi Tâl
Cyfeirir at ddata a drosglwyddir drwy'r Rhyngrwyd fel llwyth tâl. Mae llwyth tâl sy'n cael ei ystyried yn “drwm” angen adnoddau ychwanegol. O'i gymharu â SOAP, sy'n defnyddio XML, mae REST yn aml yn defnyddio JSON a HTTP i helpu i leihau'r llwyth tâl.
Yn nodweddiadol mae'n rhaid i'r Cleient ddefnyddio llyfrgell Cleient arbenigol gyda chod wedi'i gynhyrchu i gyrchu APIs SOAP oherwydd eu contract cyfathrebu llym iawn.
O ganlyniad, mae SOAP yn cynnig lefel llai o dynnu na REST ac mae ganddo gysylltiad agosach â'r gweinydd.
Pryd i ddefnyddio REST?
- Creu APIs cyhoeddus: Mae APIs REST yn cael eu ffafrio ar gyfer adeiladu gwasanaethau gwe cyhoeddus oherwydd eu bod yn cael eu gweld yn symlach i'w defnyddio a'u mabwysiadu nag API SOAP. Yn ogystal, mae SOAP yn cynnig nifer o fesurau diogelwch adeiledig nad oes gan REST, er nad oes angen y nodweddion hyn wrth weithio gyda data a gwasanaethau agored.
- Adeiladu apiau symudol: Mae REST yn berffaith ar gyfer adeiladu cymwysiadau symudol gan ei fod yn fach, yn effeithiol, yn ddi-wladwriaeth ac yn storfa.
- Defnyddio adnoddau gweinydd prin a lled band: Rhaid i bob cais i API REST fod yn ddi-wladwriaeth, sy'n golygu bod pob rhyngweithiad ar wahân a bod pob cais ac ymateb yn cynnwys yr holl ddata angenrheidiol i gwblhau'r rhyngweithiad hwnnw. Nid yw'r gweinydd yn cadw cofnodion o geisiadau blaenorol gan ei fod yn trin pob un fel cais newydd. O ganlyniad, mae angen llawer llai o gof ar y gweinydd ac mae'n gweithredu'n gyflymach oherwydd nad yw cais yn gofyn am weithredu pellach nac adfer data hanesyddol.
Pryd i ddefnyddio SEBON?
- Creu APIs preifat, yn enwedig ar gyfer busnesau mawr: Mae SEBON yn berffaith ar gyfer cymwysiadau corfforaethol gan ei fod yn galluogi llif data mewn amgylchedd datganoledig, gwasgaredig ac mae'n cynnwys nifer o nodweddion diogelwch ar-lein.
- Defnyddio protocol trafnidiaeth heblaw HTTP fel yr haen waelodol: Nid yw SEBON yn dibynnu ar HTTP fel yr haen waelodol. Yn dibynnu ar eich cais, gallech ddefnyddio SMTP (Protocol Trosglwyddo Post Syml), JMS (Java Messaging Service), neu brotocol trafnidiaeth arall.
- Gweithio gyda gweithrediadau parchus: Yn wahanol i geisiadau i REST APIs, mae ceisiadau i SOAP APIs yn wladwriaethol, sy'n golygu bod y gweinydd yn arbed gwybodaeth am y cleient ac yn ei defnyddio ar draws cadwyn o geisiadau neu weithrediadau. Hyd yn oed tra bod hyn yn defnyddio mwy o led band gweinyddwr ac adnoddau, mae'n hanfodol ar gyfer cyflawni gweithredoedd arferol neu gysylltiedig, fel trosglwyddiadau banc.
Casgliad
Mae'r gymhariaeth rhwng REST a SOAP APIs yn ei gwneud hi'n eithaf amlwg bod REST yn well na SOAP. Hyd yn oed eto, mae yna sefyllfaoedd lle mae angen API SEBON. Mewn rhai achosion, mae gwasanaethau gwe yn cael eu creu trwy gyfuno REST a SOAP APIs.
Felly, bydd yr achos defnydd yn pennu pa arddull API fydd yn gweithio orau.
Gadael ymateb