Вы хочаце звязаць сваю праграму з Facebook, каб яна магла ствараць паведамленні аўтаматычна, або з Instagram, каб вы маглі перапосціць фатаграфіі з пэўнымі хэштэгамі?
Вы таксама можаце ўключыць відэа з YouTube на свой сайт. Інтэрфейсы прыкладнога праграмавання дазваляюць выконваць усе гэтыя і іншыя задачы (API).
Розныя прыкладанні могуць «размаўляць» адно з адным бяспечным і стандартызаваным спосабам дзякуючы такім API, як Instagram API, Facebook API і YouTube API.
Іншымі словамі, праграма можа браць функцыі або даныя з іншага праграмнага забеспячэння і выкарыстоўваць іх для паляпшэння ўласных функцый або карыстацкага досведу. Але як прыкладанні могуць рабіць гэтыя запыты, апрацоўваць іх і адказваць на іх такім чынам, каб іншыя маглі зразумець?
Гэта залежыць ад таго, як быў створаны API. Пры абмеркаванні дызайну API (інтэрфейсу прыкладнога праграмавання) звычайна параўноўваюць SOAP і REST, дзве найбольш вядомыя парадыгмы API.
Як толькі SOAP API (просты пратакол доступу да аб'ектаў) стаў залатым стандартам для такіх фірмаў, як Oracle, Sun і PayPal, праз год ці каля таго была роўная і супрацьлеглая рэакцыя на API REST ад Google, Amazon і eBay.
У гэтай публікацыі мы параўнаем і супаставім SOAP API з REST API, каб вы маглі вырашыць, што лепш для вашых мэтаў.
Мы пачнем з вызначэння API.
Што такое API?
Інтэрфейс прыкладнога праграмавання называецца API. API - гэта, па сутнасці, набор метадаў і функцый, якія дазваляюць распрацоўваць прыкладанні. Яны атрымліваюць доступ да інфармацыі і функцый розных праграм, сэрвісаў або аперацыйных сістэм.
Яны служаць свайго роду пасярэднікам паміж рознымі праграмнымі сістэмамі. Яны дазваляюць «размаўляць» паміж двума не звязанымі праграмамі.
Давайце возьмем прыклад біржавога маклера, які актыўна займаецца гандлем і фінансавымі рынкамі. Зборнік аўтаматызаваны алгарытмы гандлю можна падключыць да любімай платформы трэйдара праз API. Гэта дазваляе вам, трэйдару, здзяйсняць электронныя транзакцыі або бачыць даныя аб каціроўках і цэнах у рэжыме рэальнага часу.
Што такое REST?
Сапраўдныя API "вэб-сэрвісаў" уключаюць REST (Representational State Transfer). API-інтэрфейсы REST пабудаваны на аснове URI (уніфікаваных ідэнтыфікатараў рэсурсаў, з якіх URL з'яўляецца асаблівым відам), пратаколу HTTP і неверагодна сумяшчальнага з браўзерам фармату даных JSON.
Пратакол SOAP, як мы ўжо заяўлялі, таксама можа быць выкарыстаны. REST API можна лёгка ствараць і пашыраць, але яны таксама могуць быць велізарнымі і складанымі — усё залежыць ад таго, як яны ствараюцца, пашыраюцца і для чаго яны прызначаны.
Абмежаванні рэсурсаў, паніжаныя патрабаванні да бяспекі, сумяшчальнасць з кліентам браўзера, магчымасць выяўлення, працаздольнасць даных і маштабаванасць - гэта некаторыя прычыны, па якіх вы хацелі б распрацаваць API, які будзе RESTful - рэчы, якія насамрэч прымяняюцца да вэб-сэрвісаў.
REST прапануе больш лёгкі варыянт. SOAP было складана выкарыстоўваць і абцяжарваць многіх распрацоўшчыкаў. Напрыклад, выкарыстанне SOAP з JavaScript патрабуе напісання вялікай колькасці кода для выканання простых аперацый, паколькі неабходная структура XML павінна стварацца кожны раз.
REST (як правіла) выкарыстоўвае прамы URL замест запыту XML. Хаця бываюць рэдкія выпадкі, калі вы павінны прапанаваць больш падрабязную інфармацыю, большасць вэб-сэрвісаў RESTful выкарыстоўваюць толькі метад URL.
Чатыры дзеясловы HTTP 1.1 GET, POST, PUT і DELETE могуць выкарыстоўвацца REST для выканання аперацый. У адрозненне ад SOAP, REST не патрабуе, каб адказ быў у XML.
Даступныя вэб-службы на аснове REST, якія выводзяць даныя ў фарматах Command Separated Value (CSV), JavaScript Object Notation (JSON) і Really Simple Syndication (RSS) (RSS).
Мэта складаецца ў тым, каб вы маглі атрымаць неабходныя вынікі ў фармаце, які лёгка разабраць, на мове, якую вы выкарыстоўваеце для свайго прыкладання.
Асаблівасці
- REST падкрэслівае прастату перш за ўсё, дзякуючы пратаколам HTTP.
- Інтэрнэт лепш за ўсё падыходзіць для REST. Ён сумяшчальны з браўзерамі, таму што ў якасці фармату даных выкарыстоўваецца JSON.
- REST славіцца сваёй выдатнай маштабаванасцю і хуткасцю.
- Злучэнні кліент-сервер і архітэктуры сталі больш даступнымі дзякуючы REST API. Калі гэта RESTful, ён пабудаваны з выкарыстаннем гэтай мадэлі кліент-сервер, з двума бакамі, перадаючы карысныя дадзеныя.
- REST API выкарыстоўвае адзіны стандартны інтэрфейс. Забеспячэнне аднолькавага злучэння ўсіх праграм і праз адзін і той жа шлюз спрашчае ўзаемадзеянне праграм з API.
Што такое SOAP?
Яго ўласны пратакол, які называецца SOAP (Simple Object Access Protocol), крыху больш складаны, чым REST, паколькі ён вызначае больш стандартаў, у тым ліку стандартаў, звязаных з бяспекай і дастаўкай паведамленняў.
Гэтыя неад'емныя нормы маюць невялікія дадатковыя выдаткі. Тым не менш, яны могуць быць вырашальным фактарам для прадпрыемстваў, якім патрэбныя больш шырокія магчымасці бяспекі, транзакцый і адпаведнасці патрабаванням ACID (атамарнасць, кансістэнцыя, ізаляцыя, трываласць).
Дзеля гэтага параўнання важна адзначыць, што многія з пераваг SOAP часта не прымяняюцца да прыкладанняў вэб-сэрвісаў, што робіць іх больш прыдатнымі для сцэнарыяў карпаратыўнага тыпу.
Больш высокія ступені бяспекі (напрыклад, калі а прыкладання ўзаемадзейнічае з банкам), прыкладанні для абмену паведамленнямі, якія патрабуюць надзейнай сувязі, узаемадзеянне са старымі сістэмамі або адпаведнасць ACID - гэта некалькі прычын, па якіх вы хацелі б распрацаваць прыкладанне з выкарыстаннем SOAP API.
Магчымасці абмену паведамленнямі, прапанаваныя SOAP, цалкам заснаваныя на XML. Старыя несумяшчальныя з Інтэрнэтам тэхналогіі, такія як Distributed Component Object Model (DCOM) і Common Object Request Broker Architecture, былі заменены на SOAP, калі ён быў створаны Microsoft (CORBA).
Залежнасць ад бінарнай сувязі прыводзіць да збою гэтых сістэм. Праз Інтэрнэт абмен паведамленнямі XML, падобны да таго, які выкарыстоўвае SOAP, працуе лепш.
Асаблівасці
- Бяспека SOAP значна больш жорсткая. WS-Security - гэта ўбудаваны стандарт, які прапануе SOAP дадатковыя магчымасці бяспекі на ўзроўні прадпрыемства, калі гэта неабходна ў дадатак да падтрымкі SSL.
- Паспяховае/паўтарыць аргументацыю для надзейнай працы абмену паведамленнямі. Паколькі ў REST адсутнічае стандартызаваны механізм паведамленняў, ён можа паўтарыць спробу толькі ў выпадку збою сувязі. Нават пры выкарыстанні прамежкавых звёнаў SOAP SOAP забяспечвае скразную надзейнасць дзякуючы ўбудаванай логіцы паспяховай/паўторнай спробы.
- SOAP ужо адпавядае стандартам ACID. Вызначаючы, як транзакцыі могуць узаемадзейнічаць з базай дадзеных, адпаведнасць ACID зводзіць да мінімуму анамаліі і забяспечвае паслядоўнасць базы дадзеных. Паколькі ACID з'яўляецца больш асцярожным, чым іншыя мадэлі ўзгодненасці даных, ён часта выкарыстоўваецца пры кіраванні канфідэнцыйнымі транзакцыямі, няхай гэта будзе фінансавыя або іншыя.
- Праграмістам гэта лёгка зразумець, бо SOAP - гэта сувязь, цалкам заснаваная на XML.
- Пратакол абмену паведамленнямі XML з'яўляецца дадаткам да пратаколу HTTP.
- Сувязь ад аднаго камп'ютара да іншага можа распаўсюджвацца з дапамогай паведамленняў SOAP.
- Таксама можа быць рэалізавана архітэктура кліент-сервер. Паведамленне пратакола SOAP можа быць выкарыстана кліентам для выкліку аддаленага выкліку працэдуры, якая знаходзіцца на баку сервера.
Адрозненні паміж REST і SOAP
1. Архітэктура
API прызначаны ў першую чаргу для паказу пэўных кампанентаў бізнес-логікі прыкладання на серверы. У той час як REST выкарыстоўвае URI для тых жа мэт, SOAP выкарыстоўвае для гэтага інтэрфейс службы.
REST API ствараюцца пасля даных, тады як SOAP API распрацоўваюцца пасля функцыянальных магчымасцей, якія ілюструе API. У параўнанні з SOAP, які больш кіруецца функцыямі, REST з'яўляецца больш кіраваным дадзенымі дызайнам.
2. кэшаванне
Даныя, пазначаныя як кэшуемыя, могуць зноў выкарыстоўвацца браўзерамі без неабходнасці рабіць новы запыт на сервер. Перавагай гэтага з'яўляецца эканомія часу і сіл.
Адказы не будуць кэшавацца на ўзроўні HTTP, паколькі запыты SOAP адпраўляюцца праз запыты POST, якія стандарт HTTP лічыць неідэмпатынтнымі. Калі вы хочаце выкарыстоўваць кэшаванне, вы ўсё роўна павінны стварыць неабходныя метады, бо REST API не ўключае гэтую рэалізацыю.
3. Рэсурсы і прапускная здольнасць
З-за перадачы карыснай нагрузкі ў стылі канверта, якая выкарыстоўваецца SOAP, назіраецца сціплае павелічэнне накладных выдаткаў, што патрабуе дадатковай прапускной здольнасці. Лёгкі характар REST з'яўляецца перавагай у такіх сітуацыях, таму што ён звычайна выкарыстоўваецца для вэб-сэрвісаў.
4. Бяспека
WS-бяспека, якую падтрымлівае SOAP і крыху больш дбайная, чым SSL на транспартным узроўні, пажадана. Уключэнне ў яго мер бяспекі на ўзроўні прадпрыемства таксама ідэальна падыходзіць.
Скразное шыфраванне з выкарыстаннем SSL падтрымліваецца SOAP і REST, а REST можа выкарыстоўваць HTTPS, бяспечны варыянт пратаколу HTTP.
5. Апрацоўка карысных нагрузак
Дадзеныя, якія перадаюцца праз Інтэрнэт, называюцца карыснай нагрузкай. Карысная нагрузка, якая лічыцца «цяжкай», патрабуе дадатковых рэсурсаў. У параўнанні з SOAP, які выкарыстоўвае XML, REST часта выкарыстоўвае JSON і HTTP, каб дапамагчы паменшыць карысную нагрузку.
Спецыялізаваная кліенцкая бібліятэка са згенераваным кодам звычайна павінна выкарыстоўвацца кліентам для доступу да SOAP API з-за іх надзвычай строгага кантракта на сувязь.
У выніку SOAP прапануе меншы ўзровень абстракцыі, чым REST, і больш цесна звязаны з серверам.
Калі выкарыстоўваць REST?
- Стварэнне публічных API: REST API аддаюць перавагу для стварэння агульнадаступных вэб-сэрвісаў, таму што яны прасцейшыя ў выкарыстанні і прыняцці, чым SOAP API. Акрамя таго, SOAP прапануе некалькі ўбудаваных мер бяспекі, якіх REST не мае, хоць гэтыя характарыстыкі не патрабуюцца пры працы з адкрытымі дадзенымі і службамі.
- Стварэнне мабільных прыкладанняў: REST ідэальна падыходзіць для стварэння мабільных прыкладанняў, паколькі ён невялікі, эфектыўны, не мае статусу і кэшуецца.
- Выкарыстанне абмежаваных рэсурсаў сервера і прапускной здольнасці: Усе запыты да REST API павінны быць без стану, што азначае, што кожнае ўзаемадзеянне асобнае, і кожны запыт і адказ утрымліваюць усе дадзеныя, неабходныя для завяршэння гэтага ўзаемадзеяння. Сервер не захоўвае запісы папярэдніх запытаў, бо разглядае кожны як новы запыт. У выніку сервер патрабуе значна менш памяці і працуе хутчэй, таму што запыт не патрабуе далейшых дзеянняў або атрымання гістарычных даных.
Калі выкарыстоўваць SOAP?
- Стварэнне прыватных API, асабліва для буйных кампаній: SOAP ідэальна падыходзіць для карпаратыўных прыкладанняў, паколькі забяспечвае паток даных у дэцэнтралізаваным, размеркаваным асяроддзі і змяшчае некалькі функцый бяспекі ў Інтэрнэце.
- Выкарыстанне транспартнага пратаколу, акрамя HTTP, у якасці базавага ўзроўню: SOAP не залежыць ад HTTP як базавага ўзроўню. У залежнасці ад вашай праграмы вы можаце выкарыстоўваць SMTP (просты пратакол перадачы пошты), JMS (служба абмену паведамленнямі Java) або іншы транспартны пратакол.
- Праца з аперацыямі з захаваннем стану: У адрозненне ад запытаў да REST API, запыты да SOAP API захоўваюць стан, што азначае, што сервер захоўвае інфармацыю аб кліенце і выкарыстоўвае яе ў ланцужку запытаў або аперацый. Нават калі гэта выкарыстоўвае больш прапускной здольнасці і рэсурсаў сервера, гэта вельмі важна для выканання звычайных або звязаных дзеянняў, такіх як банкаўскія пераводы.
заключэнне
Параўнанне паміж REST і SOAP API робіць цалкам відавочным, што REST пераважней SOAP. Тым не менш, бываюць сітуацыі, калі патрабуецца SOAP API. У некаторых выпадках вэб-сэрвісы ствараюцца шляхам спалучэння REST і SOAP API.
Такім чынам, варыянт выкарыстання будзе вызначаць, які стыль API будзе працаваць лепш за ўсё.
Пакінуць каментар