Zure aplikazioa lotu nahi al duzu Facebook-era, argitalpenak automatikoki sor ditzan, edo Instagram-era, argazkiak hashtag batzuekin berriro argitaratzeko?
Zure webgunean YouTube bideoak ere sartu nahi dituzu. Aplikazioak programatzeko interfazeek zeregin horiek guztiak eta gehiago (APIak) egiteko aukera ematen dute.
Aplikazio ezberdinek modu seguru eta estandarizatu batean "hitz egin" dezakete Instagram API, Facebook API eta YouTube API bezalako APIei esker.
Beste era batera esanda, programa batek beste software bateko ezaugarriak edo datuak har ditzake eta bere ezaugarriak edo erabiltzailearen esperientzia hobetzeko erabil ditzake. Baina nola egin ditzakete aplikazioek eskaera horiek, prozesatu eta erantzun dezakete besteek uler dezaketen moduan?
Hori APIa nola sortu den araberakoa da. API (aplikazioen programazio interfazea) diseinuei buruz hitz egiten denean, ohikoa da SOAP eta REST alderatzea, API paradigma nabarmenenetako bi.
SOAP APIak (Simple Object Access Protocol) Oracle, Sun eta PayPal bezalako enpresentzako urrezko estandar bihurtu bezain laster, urtebete beranduago Google, Amazon eta eBay-ren REST APIen erantzun berdina eta kontrakoa izan zen.
Argitalpen honetan, SOAP APIak REST APIekin konparatu eta kontrastatuko ditugu, zure helburuetarako egokiena zein den erabaki dezazun.
APIa definitzen hasiko gara.
Zer da APIa?
Aplikazioen Programazio Interfazea API deritzo. APIak, funtsean, aplikazioak garatzea ahalbidetzen duten metodo eta funtzioen bilduma dira. Programa, zerbitzu edo sistema eragile ezberdinen informazio eta funtzioetara sarbidea lortzen dute.
Software sistema ezberdinen arteko bitartekari moduko gisa balio dute. Loturarik gabeko bi programen artean "hitz egitea" ahalbidetzen dute.
Har dezagun merkataritzan eta finantza-merkatuetan aktiboki parte hartzen duen burtsa-artekari baten adibidea. Automatizatuen bilduma merkataritza algoritmoak API baten bidez dendariaren merkataritza-artekarien plataforma gogokoenera konekta daiteke. Horri esker, dendari, transakzio elektronikoak egiteko edo denbora errealeko aurrekontuak eta prezioen datuak ikusteko.
Zer da ATSEDENERA?
Egiazko "web-zerbitzuen" APIek REST (Representational State Transfer) barne hartzen dute. REST APIak URI (Baliabideen Identifikatzaile Uniformeak, URL mota berezia da), HTTP protokoloan eta arakatzailearekin bateragarria den JSON datu-formatuetan eraikitzen dira.
SOAP protokoloa, lehen esan dugun bezala, baliteke beharbada ere erabiltzea. REST APIak errazak izan daitezke sortu eta hazten, baina izugarriak eta zailak ere izan daitezke; hori guztia nola sortu, hedatu eta zer egin nahi duten araberakoa da.
Baliabideen mugak, segurtasun eskakizun murrizketa, arakatzailearen bezeroen bateragarritasuna, aurkigarritasuna, datuen osasuna eta eskalagarritasuna dira API bat RESTful izateko garatu nahi duzun arrazoi batzuk, web-zerbitzuei benetan aplikatzen zaizkien gauzak.
REST aukera arinagoa eskaintzen du. XABOIA erabiltzeko zaila zen eta garatzaile askorentzat astuna zen. Adibidez, SOAP JavaScript-ekin erabiltzeak kode asko idaztea eskatzen du eragiketa errazak burutzeko, behar den XML egitura sortu behar baita bakoitzean.
REST-ek (normalean) URL zuzena erabiltzen du XML eskaera baten ordez. Xehetasun gehiago eskaini behar dituzun kasu gutxitan egon arren, RESTful web zerbitzu gehienek URL teknika soilik erabiltzen dute.
GET, POST, PUT eta DELETE HTTP 1.1 lau adizkiak REST-ek erabil ditzake eragiketak egiteko. SOAP-ek ez bezala, REST-ek ez du erantzuna XML-n egon behar.
REST-en oinarritutako web zerbitzuak Command Separated Value (CSV), JavaScript Object Notation (JSON) eta Really Simple Syndication (RSS) formatuetan ateratzen dituzten datuak eskuragarri daude (RSS).
Helburua da behar dituzun emaitzak aztertzeko erraza den formatuan lor ditzakezu zure aplikaziorako erabiltzen ari zaren hizkuntzan.
Ezaugarriak
- REST-ek sinpletasuna azpimarratzen du beste guztiaren gainetik, HTTP protokoloei esker.
- Weba REST-erako egokiena da. Nabigatzaileekin bateragarria da JSON datu-formatu gisa erabiltzen delako.
- REST bere eskalagarritasun eta abiadura bikainagatik ezaguna da.
- Bezero-zerbitzariko konexioak eta arkitekturak eskuragarriago egiten dituzte REST APIek. RESTful bada, bezero-zerbitzari eredu hau erabiliz eraikitzen da, bi aldeen arteko joan-etorriekin datu-kargak pasatzen dituztenak.
- REST APIek interfaze estandar bakar bat erabiltzen dute. Aplikazio guztiak uniformeki eta atebide beraren bidez konektatzen direla bermatuz, aplikazioak APIarekin nola komunikatzen diren errazten du.
Zer da XABOIA?
Bere protokolo propioa, SOAP (Simple Object Access Protocol) izenekoa, REST baino apur bat konplikatuagoa da, estandar gehiago zehazten baititu, segurtasunarekin eta mezuen bidalketarekin lotutakoak barne.
Berezko arau hauek gastu gehigarri apur bat ekartzen dute. Hala ere, faktore erabakigarriak izan daitezke segurtasun, transakzio eta ACID (Atomicity, Consistency, Isolation, Durability) betetzeko gaitasun zabalagoak behar dituzten enpresentzat.
Konparaketa honen mesedetan, kontuan izan behar da SOAP-en onura asko ez direla askotan aplikatzen web-zerbitzuen aplikazioetan, enpresa motako agertokietarako egokiago bihurtuz.
Segurtasun maila altuagoak (adibidez, a mobile app banku batekin elkarreragiten du), komunikazio fidagarria behar duten mezularitza-aplikazioak, antzinako sistemekin elkarreragina edo ACID betetzea dira SOAP API bat erabiliz aplikazio bat diseinatu nahi duzun arrazoi batzuk.
SOAPek eskaintzen dituen mezularitza-gaitasunak XMLn oinarritzen dira erabat. Internetekin bateraezinak diren teknologia zaharragoak, hala nola Distributed Component Object Model (DCOM) eta Common Object Request Broker Architecture, SOAP-ek ordezkatu zituen Microsoft-ek (CORBA) sortu zuenean.
Komunikazio bitarrekiko konfiantzak sistema horiek huts egiten dute. Interneten bidez, SOAPek erabiltzen dituen XML mezuak hobeto funtzionatzen du.
Ezaugarriak
- SOAP-en segurtasuna nabarmenagoa da. WS-Security SSL euskarriaz gain enpresa-mailako segurtasun gaitasun gehigarriak eskaintzen dituen estandar integratua da.
- Arrazoi arrakastatsua/berriro saiatu mezularitza-errendimendu fidagarrirako. REST-ek mezu-mekanismo estandarizaturik ez duenez, komunikazioak huts egiten duenean soilik saiatu daiteke berriro. SOAP bitartekoak erabiltzen badituzu ere, SOAPek muturreko fidagarritasuna eskaintzen du integratutako arrakasta/berriro saiatzeko logika dela eta.
- SOAPek ACID estandarrak betetzen ditu dagoeneko. Transakzioek datu-basearekin nola interakzionatu dezaketen aginduz, ACID betetzeak anomaliak gutxitzen ditu eta datu-base baten koherentzia bermatzen du. ACID beste datuen koherentzia ereduak baino zuhurragoa denez, maiz erabiltzen da transakzio sentikorrak kudeatzen direnean, finantzak edo bestelakoak izan.
- Programatzaileentzat erraza da ulertzea SOAP guztiz XMLn oinarritutako komunikazioa baita.
- XML mezularitza protokoloa HTTP protokoloaren gehigarria da.
- Ordenagailu batetik beste ordenagailuetara komunikazioak SOAP mezuen bidez heda daitezke.
- Bezero-zerbitzariaren arkitektura ere inplementa daiteke. SOAP protokolo-mezu bat erabil dezake bezeroak zerbitzariaren aldean dagoen urruneko prozedura-dei bati deitzeko.
REST Vs SOAP Desberdintasunak
1. arkitektura
API batek zerbitzari batean aplikazio baten negozio-logikaren osagai zehatzak erakustea du helburu. REST-ek URIak helburu bererako erabiltzen dituen bitartean, SOAPek Zerbitzu Interfazea erabiltzen du horretarako.
REST APIak datuen ondoren sortzen dira, SOAP APIak, berriz, APIak erakusten dituen funtzionalitateen ondoren garatzen dira. Funtzioetan oinarritutako SOAP-arekin alderatuta, REST datuetan oinarritutako diseinua da.
2. Caching
Cache gisa markatu diren datuak arakatzaileek berriro erabil ditzakete zerbitzariari eskaera berri bat egin behar izan gabe. Denbora eta ahalegina aurreztea da honen onura.
Erantzunak ez dira cachean gordeko HTTP mailan, SOAP kontsultak POST eskaeren bidez bidaltzen baitira, HTTP estandarrak ez-ipotentetzat jotzen dituena. Cachea erabili nahi baduzu, beharrezkoak diren teknikak eraiki behar dituzu oraindik, REST APIek ez baitute inplementazio hau barne hartzen.
3. Baliabideak eta banda zabalera
SOAPek erabiltzen duen gutun-azal-estiloko karga-kargaren transferentzia dela eta, gastuen gehikuntza xume bat dago, eta horrek banda zabalera gehigarria behar du. REST-en izaera arina onuragarria da egoera hauetan, orokorrean web zerbitzuetarako erabiltzen delako.
4. Segurtasuna
WS-segurtasuna, SOAPek onartzen duena eta garraio mailan SSL baino apur bat sakonagoa dena, desiragarria da. Enpresa-mailako segurtasun-neurriak barne hartzea ere ezin hobea da.
SSL erabiliz muturreko enkriptatzea SOAPek eta RESTek onartzen dute, eta RESTek HTTPS erabil dezake, HTTP protokoloaren aldaera segurua.
5. Kargak maneiatzea
Internet bidez transmititzen diren datuei karga karga gisa esaten zaie. "Astuntzat" jotzen den karga batek baliabide gehigarriak behar ditu. XML erabiltzen duen SOAParekin alderatuta, REST-ek JSON eta HTTP erabiltzen ditu sarritan karga murrizten laguntzeko.
Sortutako kodea duen Bezero-liburutegi espezializatu bat normalean erabili behar du Bezeroak SOAP APIetara sartzeko, komunikazio-kontratu oso zorrotza duelako.
Ondorioz, SOAPek REST baino abstrakzio maila txikiagoa eskaintzen du eta zerbitzariarekin estuago dago lotuta.
Noiz erabili REST?
- API publikoak sortzea: REST APIak hobesten dira web-zerbitzu publikoak eraikitzeko, SOAP APIak baino erabiltzeko eta hartzeko errazagoak direla ikusten delako. Gainera, SOAPek RESTek ez dituen hainbat segurtasun-neurri barne eskaintzen ditu, nahiz eta ezaugarri horiek beharrezkoak ez diren datu eta zerbitzu irekiekin lan egiten denean.
- Mugikorretarako aplikazioak eraikitzea: REST ezin hobea da mugikorrentzako aplikazioak eraikitzeko, txikia, eraginkorra, estaturik gabekoa eta cachea baita.
- Zerbitzariaren baliabide eta banda-zabalera urriak erabiltzea: REST API bati egindako eskaera guztiek estaturik gabekoak izan behar dute, hau da, elkarrekintza bakoitza bereizita dago eta eskaera eta erantzun bakoitzak elkarrekintza hori osatzeko beharrezkoak diren datu guztiak ditu. Zerbitzariak ez ditu aurreko eskaeren erregistroak gordetzen, bakoitza eskaera berri gisa tratatzen baitu. Ondorioz, zerbitzariak askoz memoria gutxiago behar du eta azkarrago funtzionatzen du, eskaera batek ez duelako ekintza gehiago behar edo datu historikoak berreskuratu behar.
Noiz erabili XABOIA?
- API pribatuak sortzea, bereziki enpresa handientzat: SOAP ezin hobea da aplikazio korporatiboetarako, datu-fluxua ahalbidetzen baitu ingurune deszentralizatu eta banatu batean eta lineako segurtasun-eginbide ugari dituelako.
- HTTP ez den beste garraio-protokolo bat erabiliz azpiko geruza gisa: SOAP ez dago HTTPren menpeko azpiko geruza gisa. Zure aplikazioaren arabera, SMTP (Simple Mail Transfer Protocol), JMS (Java Messaging Service) edo beste garraio-protokolo bat erabil ditzakezu.
- Estatuko eragiketekin lan egitea: REST APIetarako eskaerekin alderatuta, SOAP APIetarako eskaerak egoerakoak dira, hau da, zerbitzariak bezeroari buruzko informazioa gordetzen du eta eskaera edo eragiketa kate batean erabiltzen du. Honek zerbitzariaren banda-zabalera eta baliabide gehiago erabiltzen baditu ere, funtsezkoa da ekintza arruntak edo lotuak egiteko, banku-transferentziak adibidez.
Ondorioa
REST eta SOAP APIen arteko konparaketak argi uzten du REST SOAP baino hobe dela. Hala ere, badaude SOAP APIa beharrezkoa den egoerak. Zenbait kasutan, web zerbitzuak REST eta SOAP APIak konbinatuz sortzen dira.
Hori dela eta, erabilera kasuak zehaztuko du zein API estilo funtzionatuko duen onena.
Utzi erantzun bat