Да ли желите да повежете своју апликацију са Фацебоок-ом како би могла аутоматски да генерише постове или са Инстаграмом како бисте могли да поново постављате фотографије са одређеним хасхтаговима?
Такође бисте могли да укључите ИоуТубе видео снимке на своју веб локацију. Интерфејси за програмирање апликација вам омогућавају да обављате све ове задатке и више (АПИ).
Различите апликације могу да „разговарају” једна са другом на безбедан и стандардизован начин захваљујући АПИ-јима као што су Инстаграм АПИ, Фацебоок АПИ и ИоуТубе АПИ.
Другим речима, програм може да преузме карактеристике или податке из другог софтвера и да их користи за побољшање сопствених карактеристика или корисничког искуства. Али како апликације могу да упућују ове захтеве, обрађују их и одговоре на њих на начин који други могу разумети?
То зависи од тога како је АПИ креиран. Када се расправља о дизајну АПИ-ја (интерфејса за програмирање апликације), уобичајено је да се пореди СОАП и РЕСТ, две најистакнутије парадигме АПИ-ја.
Чим су СОАП АПИ-ји (Симпле Објецт Аццесс Протоцол) постали златни стандард за фирме као што су Орацле, Сун и ПаиПал, постојао је једнак и супротан одговор годину дана касније на РЕСТ АПИ-је од Гугла, Амазона и еБаиа.
У овом посту ћемо упоредити и упоредити СОАП АПИ-је са РЕСТ АПИ-јима како бисте могли да одлучите који је најбољи за ваше потребе.
Почећемо са дефинисањем АПИ-ја.
Шта је АПИ?
Програмски интерфејс апликације се назива АПИ. АПИ-ји су у суштини скуп метода и функција које омогућавају развој апликација. Они добијају приступ информацијама и функцијама различитих програма, услуга или оперативних система.
Они служе као нека врста посредника између различитих софтверских система. Они омогућавају „разговор“ између два неповезана програма.
Узмимо пример берзанског посредника који је активно укључен у трговину и финансијска тржишта. Збирка аутоматизованих трговачки алгоритми може бити повезан са омиљеном платформом трговачког брокера трговца преко АПИ-ја. Ово омогућава вама, трговцу, да извршите електронске трансакције или да видите понуде и податке о ценама у реалном времену.
Шта је РЕСТ?
Прави АПИ-ји „веб услуга“ укључују РЕСТ (пренос репрезентативног стања). РЕСТ АПИ-ји су изграђени на УРИ-овима (Униформ Ресоурце Идентифиерс, од којих је УРЛ посебна врста), ХТТП протоколу и невероватно компатибилном ЈСОН формату података за претраживач.
СОАП протокол, као што смо већ рекли, можда би такође могао да се користи. РЕСТ АПИ-ји могу бити лаки за креирање и развој, али такође могу бити огромни и тешки — све зависи од тога како су креирани, проширени и шта намеравају да ураде.
Ограничења ресурса, смањени безбедносни захтеви, компатибилност са клијентима претраживача, могућност откривања, здравље података и скалабилност су неки од разлога због којих бисте желели да развијете АПИ који ће бити РЕСТфул – ствари које се заправо примењују на веб услуге.
РЕСТ нуди лакшу опцију. СОАП је био тежак за коришћење и оптерећујући многе програмере. На пример, коришћење СОАП-а са ЈаваСцрипт-ом захтева писање много кода да би се довршиле једноставне операције пошто се неопходна КСМЛ структура мора креирати сваки пут.
РЕСТ (обично) користи директну УРЛ адресу уместо КСМЛ захтева. Иако постоје ретке околности када морате да понудите више детаља, већина РЕСТфул веб услуга користи само УРЛ технику.
Четири ХТТП 1.1 глагола ГЕТ, ПОСТ, ПУТ и ДЕЛЕТЕ РЕСТ може користити за обављање операција. За разлику од СОАП-а, РЕСТ-у не треба да одговор буде у КСМЛ-у.
Доступни су веб сервиси засновани на РЕСТ-у који емитују податке у форматима са вредностима одвојеним наредбама (ЦСВ), ЈаваСцрипт нотацијом објеката (ЈСОН) и заиста једноставном објавом (РСС).
Циљ је да добијете резултате који су вам потребни у формату који се лако анализира у оквиру језика који користите за своју апликацију.
Карактеристике
- РЕСТ наглашава једноставност изнад свега, захваљујући ХТТП протоколима.
- Веб је најпогоднији за РЕСТ. Компатибилан је са претраживачима јер се ЈСОН користи као формат података.
- РЕСТ је познат по својој изванредној скалабилности и брзини.
- РЕСТ АПИ-ји чине приступачнијим везама и архитектурама клијент-сервер. Ако је РЕСТфул, конструисан је коришћењем овог клијент-сервер модела, са кружним путовањима између две стране које преносе корисне податке.
- РЕСТ АПИ-ји користе усамљени стандардни интерфејс. Обезбеђивање да се све апликације повезују једнолично и преко истог мрежног пролаза, поједностављује начин на који апликације комуницирају са АПИ-јем.
Шта је СОАП?
Његов сопствени протокол, назван СОАП (Симпле Објецт Аццесс Протоцол), је мало компликованији од РЕСТ-а јер наводи више стандарда, укључујући оне који се односе на безбедност и испоруку порука.
Ове инхерентне норме долазе са мало додатних трошкова. Међутим, они могу бити одлучујући фактор за предузећа којима је потребна већа сигурност, трансакција и АЦИД (атомичност, конзистентност, изолација, издржљивост) усаглашености.
Ради овог поређења, важно је напоменути да се многе предности СОАП-а не примењују често на апликације веб услуга, што их чини погоднијим за сценарије типа предузећа.
Виши степен сигурности (као када је а апликација за мобилне уређаје комуницира са банком), апликације за размену порука које захтевају поуздану комуникацију, интеракцију са застарелим системима или усклађеност са АЦИД-ом су неколико разлога због којих бисте желели да дизајнирате апликацију која користи СОАП АПИ.
Могућности размене порука које нуди СОАП су у потпуности засноване на КСМЛ-у. Старије технологије које нису компатибилне са интернетом, попут модела дистрибуираних компоненти (ДЦОМ) и архитектуре Цоммон Објецт Рекуест Брокер, замењене су СОАП-ом када га је први пут креирао Мицрософт (ЦОРБА).
Ослањање на бинарне комуникације узрокује неуспех ових система. Преко интернета, КСМЛ поруке попут оних које користи СОАП боље функционишу.
Карактеристике
- Сигурност СОАП-а је знатно строжа. ВС-Сецурити је уграђени стандард који нуди СОАП додатне безбедносне могућности на нивоу предузећа ако је потребно поред ССЛ подршке.
- Успешно/поновно резоновање за поуздане перформансе размене порука. Пошто РЕСТ-у недостаје стандардизовани механизам за поруке, може поново да покуша само када комуникација не успе. Чак и када се користе СОАП међупродукти, СОАП нуди поузданост од краја до краја због своје уграђене логике успешног/поновног покушаја.
- СОАП је већ у складу са АЦИД стандардима. Диктирајући начин на који трансакције могу да комуницирају са базом података, усклађеност са АЦИД-ом минимизира аномалије и чува конзистентност базе података. Пошто је АЦИД опрезнији од других модела конзистентности података, често се користи када се управља осетљивим трансакцијама, било финансијским или другим.
- Програмерима је то једноставно да схвате пошто је СОАП комуникација у потпуности заснована на КСМЛ-у.
- КСМЛ протокол за размену порука је додатак ХТТП протоколу.
- Комуникација са једног рачунара на други рачунар може се преносити путем СОАП порука.
- Архитектура клијент-сервер такође се може имплементирати. Поруку СОАП протокола клијент може користити за позивање удаљеног позива процедуре који се налази на страни сервера.
РЕСТ Вс СОАП Разлике
КСНУМКС. архитектура
АПИ је намењен првенствено да прикаже специфичне компоненте пословне логике апликације на серверу. Док РЕСТ користи УРИ-је за исту сврху, СОАП користи Сервисни интерфејс за ово.
РЕСТ АПИ-ји се креирају након података, док се СОАП АПИ-ји развијају након функционалности које АПИ илуструје. У поређењу са СОАП-ом, који је више вођен функцијама, РЕСТ је дизајн који се више заснива на подацима.
КСНУМКС. Кеширање
Подаци који су означени као кеширани могу поново да се користе од стране претраживача без потребе да упућују нови захтев серверу. Уштеда времена и труда је предност овога.
Одговори се неће кеширати на ХТТП нивоу пошто се СОАП упити шаљу путем ПОСТ захтева, за које ХТТП стандард сматра да нису идемпотентни. Ако желите да користите кеширање, и даље морате да изградите неопходне технике јер РЕСТ АПИ-ји не укључују ову имплементацију.
3. Ресурси и пропусни опсег
Због преноса терета у облику омотача који користи СОАП, долази до скромног повећања трошкова, што захтева додатни пропусни опсег. Лагана природа РЕСТ-а је предност у овим ситуацијама јер се генерално користи за веб услуге.
КСНУМКС. Безбедност
Пожељна је ВС-безбедност, коју СОАП подржава и која је нешто темељнија од ССЛ-а на нивоу транспорта. Укључивање безбедносних мера на нивоу предузећа са њим такође савршено одговара.
Шифровање од краја до краја помоћу ССЛ-а подржавају и СОАП и РЕСТ, а РЕСТ може да користи ХТТПС, безбедну варијанту ХТТП протокола.
5. Руковање корисним оптерећењем
Подаци који се преносе путем Интернета називају се корисним оптерећењем. Корисни терет који се сматра „тешким“ захтева додатне ресурсе. У поређењу са СОАП-ом, који користи КСМЛ, РЕСТ често користи ЈСОН и ХТТП да би помогао у смањењу корисног оптерећења.
Клијент обично мора да користи специјализовану клијентову библиотеку са генерисаним кодом за приступ СОАП АПИ-јима због њиховог изузетно строгог уговора о комуникацији.
Као резултат тога, СОАП нуди мањи ниво апстракције од РЕСТ-а и ближе је повезан са сервером.
Када користити РЕСТ?
- Креирање јавних АПИ-ја: РЕСТ АПИ-ји су пожељнији за изградњу јавних веб сервиса јер се сматра да су једноставнији за коришћење и усвајање од СОАП АПИ-ја. Поред тога, СОАП нуди неколико уграђених безбедносних мера које РЕСТ нема, иако ове карактеристике нису потребне када се ради са отвореним подацима и услугама.
- Израда мобилних апликација: РЕСТ је савршен за прављење мобилних апликација јер је мали, ефикасан, без државности и који се може кеширати.
- Коришћење оскудних серверских ресурса и пропусног опсега: Сви захтеви ка РЕСТ АПИ-ју морају бити без стања, што значи да је свака интеракција засебна и да сваки захтев и одговор садрже све податке неопходне за довршавање те интеракције. Сервер не чува записе претходних захтева јер сваки од њих третира као нови захтев. Као резултат тога, сервер захтева много мање меморије и ради брже јер захтев не захтева даљу радњу или преузимање историјских података.
Када користити СОАП?
- Креирање приватних АПИ-ја, посебно за велика предузећа: СОАП је савршен за корпоративне апликације јер омогућава проток података у децентрализованом, дистрибуираном окружењу и садржи неколико безбедносних функција на мрежи.
- Коришћење транспортног протокола који није ХТТП као основни слој: СОАП не зависи од ХТТП-а као основног слоја. У зависности од ваше апликације, можете да користите СМТП (Симпле Маил Трансфер Протоцол), ЈМС (Јава Мессагинг Сервице) или други транспортни протокол.
- Рад са операцијама са стањем: За разлику од захтева за РЕСТ АПИ-је, захтеви за СОАП АПИ-ји су са стањем, што значи да сервер чува информације о клијенту и користи их у ланцу захтева или операција. Чак иако ово користи више пропусног опсега и ресурса сервера, кључно је за обављање рутинских или повезаних радњи, попут банковних трансфера.
Zakljucak
Поређење између РЕСТ и СОАП АПИ-ја чини сасвим евидентним да је РЕСТ пожељнији од СОАП-а. Ипак, постоје ситуације у којима је потребан СОАП АПИ. У одређеним случајевима, веб услуге се креирају комбиновањем РЕСТ и СОАП АПИ-ја.
Према томе, случај употребе ће одредити који ће АПИ стил функционисати најбоље.
Ostavite komentar