Gusto mo bang i-link ang iyong app sa Facebook para awtomatiko itong makabuo ng mga post, o sa Instagram para makapag-repost ka ng mga larawan gamit ang ilang partikular na hashtag?
Maaari mo ring hilingin na isama ang mga video sa YouTube sa iyong website. Binibigyang-daan ka ng mga interface ng application programming na gawin ang lahat ng mga gawaing ito at higit pa (mga API).
Ang iba't ibang mga application ay maaaring "magsalita" sa isa't isa sa isang secure at standardized na paraan salamat sa mga API tulad ng Instagram API, Facebook API, at YouTube API.
Sa madaling salita, ang isang program ay maaaring kumuha ng mga feature o data mula sa isa pang piraso ng software at gamitin ang mga ito upang mapabuti ang sarili nitong mga feature o karanasan ng user. Ngunit paano magagawa ng mga app ang mga kahilingang ito, ipoproseso ang mga ito, at tutugon sa mga ito sa paraang mauunawaan ng iba?
Depende iyon sa kung paano ginawa ang API. Kapag tinatalakay ang mga disenyo ng API (application programming interface), karaniwan nang ihambing ang SOAP kumpara sa REST, dalawa sa pinakakilalang paradigm ng API.
Sa sandaling ang mga SOAP API (Simple Object Access Protocol) ay naging gold standard para sa mga kumpanya tulad ng Oracle, Sun, at PayPal, nagkaroon ng pantay at kabaligtaran na tugon sa isang taon o higit pa sa mga REST API mula sa Google, Amazon, at eBay.
Sa post na ito, ihahambing at ihahambing namin ang mga SOAP API sa mga REST API para makapagpasya ka kung alin ang pinakamainam para sa iyong mga layunin.
Magsisimula tayo sa pamamagitan ng pagtukoy sa API.
Ano ang API?
Ang Application Programming Interface ay tinutukoy bilang API. Ang mga API ay mahalagang koleksyon ng mga pamamaraan at function na nagbibigay-daan sa pagbuo ng mga app. Nagkakaroon sila ng access sa impormasyon at mga function ng iba't ibang program, serbisyo, o operating system.
Nagsisilbi sila bilang isang uri ng middleman sa pagitan ng iba't ibang mga sistema ng software. Pinapagana nila ang "pag-uusap" sa pagitan ng dalawang hindi konektadong programa.
Kunin natin ang halimbawa ng isang stockbroker na aktibong kasangkot sa pangangalakal at mga pamilihan sa pananalapi. Isang koleksyon ng mga awtomatiko mga algorithm ng kalakalan maaaring konektado sa paboritong platform ng trading broker ng mangangalakal sa pamamagitan ng API. Nagbibigay-daan ito sa iyo, ang mangangalakal, na magsagawa ng mga elektronikong transaksyon o makakita ng real-time na mga panipi at data ng pagpepresyo.
Ano ang REST?
Kasama sa mga tunay na “web services” API ang REST (Representational State Transfer). Ang mga REST API ay binuo sa mga URI (Uniform Resource Identifiers, kung saan ang isang URL ay isang espesyal na uri), ang HTTP protocol, at ang hindi kapani-paniwalang browser-compatible na format ng data ng JSON.
Ang SOAP protocol, gaya ng nasabi na natin, ay posibleng magamit din. Ang mga REST API ay maaaring madaling gawin at palakihin, ngunit maaari din silang maging napakalaki at mahirap—lahat ito ay depende sa kung paano ito nilikha, pinalawak, at kung ano ang nilalayon nilang gawin.
Ang mga hadlang sa mapagkukunan, pinababang mga kinakailangan sa seguridad, pagiging tugma ng kliyente ng browser, kakayahang matuklasan, kalusugan ng data, at scalability ay ilang dahilan kung bakit nais mong bumuo ng isang API upang maging RESTful—mga bagay na aktwal na nalalapat sa mga serbisyo sa web.
Nag-aalok ang REST ng mas magaan na opsyon. Ang SOAP ay mahirap gamitin at pabigat sa maraming developer. Halimbawa, ang paggamit ng SOAP na may JavaScript ay nangangailangan ng pagsulat ng maraming code upang makumpleto ang mga simpleng operasyon dahil ang kinakailangang istruktura ng XML ay dapat gawin sa bawat oras.
Ang REST (kadalasan) ay gumagamit ng isang direktang URL sa halip na isang kahilingan sa XML. Bagama't may mga bihirang pagkakataon kung kailan dapat kang mag-alok ng higit pang mga detalye, ang karamihan sa mga RESTful na serbisyo sa web ay gumagamit lamang ng pamamaraan ng URL.
Ang apat na HTTP 1.1 na pandiwa na GET, POST, PUT, at DELETE ay maaaring gamitin ng REST upang magsagawa ng mga operasyon. Hindi tulad ng SOAP, hindi kailangan ng REST na nasa XML ang sagot.
REST-based web services na naglalabas ng data sa Command Separated Value (CSV), JavaScript Object Notation (JSON), at Really Simple Syndication (RSS) na mga format ay available (RSS).
Ang layunin ay makuha mo ang mga resulta na kailangan mo sa isang madaling i-parse na format sa loob ng wikang ginagamit mo para sa iyong aplikasyon.
Mga tampok
- Binibigyang-diin ng REST ang pagiging simple higit sa lahat, dahil sa mga protocol ng HTTP.
- Ang web ay pinakaangkop para sa REST. Tugma ito sa mga browser dahil ginagamit ang JSON bilang format ng data.
- Ang REST ay kilala sa natatangi nitong scalability at bilis.
- Ang mga koneksyon at arkitektura ng Client-server ay ginagawang mas naa-access ng mga REST API. Kung ito ay RESTful, ito ay binuo gamit ang client-server model na ito, na may mga round trip sa pagitan ng dalawang partido na nagpapasa ng mga data payload.
- Gumagamit ang REST API ng nag-iisa na karaniwang interface. Ang pagtiyak na ang lahat ng mga app ay kumonekta nang pantay-pantay at sa pamamagitan ng parehong gateway, pinapasimple kung paano nakikipag-ugnayan ang mga application sa API.
Ano ang SOAP?
Ang sarili nitong protocol, na tinatawag na SOAP (Simple Object Access Protocol), ay medyo mas kumplikado kaysa sa REST dahil mas marami itong pamantayan, kabilang ang mga nauugnay sa seguridad at paghahatid ng mensahe.
Ang mga likas na pamantayang ito ay may kaunting dagdag na overhead. Gayunpaman, maaari silang maging mapagpasyang salik para sa mga negosyong nangangailangan ng mas malawak na seguridad, transaksyon, at mga kakayahan sa pagsunod sa ACID (Atomicity, Consistency, Isolation, Durability).
Para sa kapakanan ng paghahambing na ito, mahalagang tandaan na marami sa mga benepisyo ng SOAP ay hindi madalas na nalalapat sa mga web services application, na ginagawang mas angkop ang mga ito para sa mga sitwasyong pang-enterprise.
Mas mataas na antas ng seguridad (tulad ng kapag a mobile app nakikipag-ugnayan sa isang bangko), mga app sa pagmemensahe na nangangailangan ng maaasahang komunikasyon, pakikipag-ugnayan sa mga legacy system, o pagsunod sa ACID ay ilang dahilan kung bakit mo gustong magdisenyo ng isang application na gumagamit ng SOAP API.
Ang mga kakayahan sa pagmemensahe na inaalok ng SOAP ay ganap na nakabatay sa XML. Ang mga lumang teknolohiyang hindi tugma sa internet tulad ng Distributed Component Object Model (DCOM) at Common Object Request Broker Architecture ay pinalitan ng SOAP noong una itong ginawa ng Microsoft (CORBA).
Ang pag-asa sa binary na komunikasyon ay nagiging sanhi ng pagkabigo ng mga sistemang ito. Sa internet, mas mahusay na gumagana ang XML messaging tulad ng ginagamit ng SOAP.
Mga tampok
- Ang seguridad ng SOAP ay makabuluhang mas mahigpit. Ang WS-Security ay isang built-in na pamantayan na nag-aalok ng SOAP ng karagdagang mga kakayahan sa seguridad sa antas ng enterprise kung kinakailangan bilang karagdagan sa suporta sa SSL.
- Matagumpay/muling subukan ang pangangatuwiran para sa mapagkakatiwalaang pagganap ng pagmemensahe. Dahil kulang ang REST ng isang standardized na mekanismo ng mensahe, maaari lamang itong muling subukan kapag nabigo ang komunikasyon. Kahit na gumagamit ng mga SOAP intermediate, nag-aalok ang SOAP ng end-to-end na pagiging maaasahan dahil sa built-in na matagumpay/retry na logic nito.
- Sumusunod na ang SOAP sa mga pamantayan ng ACID. Sa pamamagitan ng pagdidikta kung paano maaaring makipag-ugnayan ang mga transaksyon sa database, pinapaliit ng pagsunod sa ACID ang mga anomalya at pinangangalagaan ang pagkakapare-pareho ng isang database. Dahil mas maingat ang ACID kaysa sa iba pang mga modelo ng pagkakapare-pareho ng data, madalas itong ginagamit kapag namamahala ng mga sensitibong transaksyon, pinansyal man o iba pa.
- Ito ay simple para sa mga programmer na maunawaan dahil ang SOAP ay isang ganap na XML-based na komunikasyon.
- Ang XML messaging protocol ay isang karagdagan sa HTTP protocol.
- Ang mga komunikasyon mula sa isang computer patungo sa ibang mga computer ay maaaring ipalaganap sa pamamagitan ng SOAP messaging.
- Ang arkitektura ng Client-server ay maaari ding ipatupad. Ang isang SOAP protocol na mensahe ay maaaring gamitin ng kliyente upang tumawag sa isang remote procedure call na nasa server-side.
REST vs SOAP Pagkakaiba
1. arkitektura
Ang isang API ay nilayon na pangunahing magpakita ng mga partikular na bahagi ng lohika ng negosyo ng isang application sa isang server. Habang ginagamit ng REST ang mga URI para sa parehong layunin, gumagamit ang SOAP ng Service Interface para dito.
Ginagawa ang mga REST API pagkatapos ng data, samantalang ang mga SOAP API ay binuo pagkatapos ng mga functionality na inilalarawan ng API. Kung ikukumpara sa SOAP, na higit na pinaandar ng pag-andar, ang REST ay isang disenyo na higit na hinihimok ng data.
2. Caching
Ang data na minarkahan bilang cacheable ay maaaring magamit muli ng mga browser nang hindi nangangailangan ng mga ito na gumawa ng bagong kahilingan sa server. Ang pagtitipid ng oras at pagsisikap ay isang benepisyo nito.
Hindi mai-cache ang mga tugon sa antas ng HTTP dahil isinumite ang mga query sa SOAP sa pamamagitan ng mga kahilingan sa POST, na itinuturing ng pamantayan ng HTTP na hindi idempotent. Kung gusto mong gumamit ng caching, dapat ka pa ring bumuo ng mga kinakailangang diskarte dahil hindi kasama sa mga REST API ang pagpapatupad na ito.
3. Mga Mapagkukunan at Bandwidth
Dahil sa envelope-style payload transfer na ginagamit ng SOAP, may katamtamang pagtaas sa overhead, na nangangailangan ng dagdag na bandwidth. Ang magaan na katangian ng REST ay isang benepisyo sa mga sitwasyong ito dahil ito ay karaniwang ginagamit para sa mga serbisyo sa web.
4. Katiwasayan
Ang WS-security, na sinusuportahan ng SOAP at bahagyang mas masinsinan kaysa sa SSL sa antas ng transportasyon, ay kanais-nais. Ang pagsasama ng mga hakbang sa seguridad sa antas ng enterprise ay isang perpektong akma din.
Ang end-to-end na pag-encrypt gamit ang SSL ay sinusuportahan ng parehong SOAP at REST, at ang REST ay maaaring gumamit ng HTTPS, ang secure na variant ng HTTP protocol.
5. Paghawak ng mga Payload
Ang data na ipinadala sa pamamagitan ng Internet ay tinutukoy bilang isang payload. Ang isang payload na itinuturing na "mabigat" ay nangangailangan ng karagdagang mga mapagkukunan. Kung ikukumpara sa SOAP, na gumagamit ng XML, ang REST ay madalas na gumagamit ng JSON at HTTP upang makatulong na bawasan ang payload.
Ang isang dalubhasang library ng Kliyente na may nabuong code ay karaniwang dapat gamitin ng Kliyente upang ma-access ang mga SOAP API dahil sa kanilang napakahigpit na kontrata sa komunikasyon.
Bilang resulta, nag-aalok ang SOAP ng mas mababang antas ng abstraction kaysa REST at mas malapit na konektado sa server.
Kailan gagamitin ang REST?
- Paglikha ng mga pampublikong API: Mas gusto ang REST API para sa pagbuo ng mga pampublikong serbisyo sa web dahil nakikitang mas simple ang mga ito na gamitin at gamitin kaysa sa mga SOAP API. Bukod pa rito, nag-aalok ang SOAP ng ilang built-in na mga hakbang sa seguridad na wala ang REST, bagama't hindi kinakailangan ang mga katangiang ito kapag nagtatrabaho sa bukas na data at mga serbisyo.
- Paggawa ng mga mobile app: Ang REST ay perpekto para sa pagbuo ng mga mobile application dahil ito ay maliit, epektibo, walang estado, at na-cache.
- Paggamit ng kakaunting mapagkukunan ng server at bandwidth: Ang lahat ng mga kahilingan sa isang REST API ay dapat na walang estado, na nangangahulugan na ang bawat pakikipag-ugnayan ay hiwalay at ang bawat kahilingan at tugon ay naglalaman ng lahat ng data na kinakailangan upang makumpleto ang pakikipag-ugnayang iyon. Ang server ay hindi nagse-save ng mga talaan ng mga nakaraang kahilingan dahil tinatrato nito ang bawat isa bilang isang bagong kahilingan. Bilang resulta, ang server ay nangangailangan ng mas kaunting memorya at nagpapatakbo nang mas mabilis dahil ang isang kahilingan ay hindi nangangailangan ng karagdagang pagkilos o ang pagkuha ng makasaysayang data.
Kailan gagamit ng SOAP?
- Paglikha ng mga pribadong API, partikular para sa malalaking negosyo: Ang SOAP ay perpekto para sa mga corporate application dahil ito ay nagbibigay-daan sa daloy ng data sa isang desentralisado, distributed na kapaligiran at naglalaman ng ilang online na mga tampok ng seguridad.
- Paggamit ng transport protocol maliban sa HTTP bilang pinagbabatayan na layer: Ang SOAP ay hindi nakadepende sa HTTP bilang pinagbabatayan na layer. Depende sa iyong aplikasyon, maaari mong gamitin ang SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service), o isa pang transport protocol.
- Nagtatrabaho sa stateful operations: Sa kaibahan sa mga kahilingan sa REST API, ang mga kahilingan sa SOAP API ay stateful, ibig sabihin, ang server ay nagse-save ng impormasyon tungkol sa kliyente at ginagamit ito sa isang hanay ng mga kahilingan o operasyon. Kahit na gumagamit ito ng mas maraming bandwidth ng server at mga mapagkukunan, mahalaga ito para sa pagsasagawa ng mga nakagawiang o naka-link na pagkilos, tulad ng mga bank transfer.
Konklusyon
Ang paghahambing sa pagitan ng REST at SOAP API ay ginagawang lubos na maliwanag na ang REST ay mas pinipili kaysa sa SOAP. Gayunpaman, may mga sitwasyon kung saan kinakailangan ang SOAP API. Sa ilang partikular na pagkakataon, ang mga serbisyo sa web ay nilikha sa pamamagitan ng pagsasama-sama ng REST at SOAP API.
Samakatuwid, tutukuyin ng use case kung aling istilo ng API ang pinakamahusay na gagana.
Mag-iwan ng Sagot