Hi! Ngayon ay matututunan natin ang tungkol sa isang paksa na lubhang kawili-wili at, pinaka-mahalaga, sa mataas na demand sa merkado ng paggawa: REST. Hahatiin namin ang aming pangkalahatang-ideya ng REST sa tatlong bahagi:
Sa unang bahagi, tatalakayin natin ang kasaysayan ng REST at ilalarawan ang mga prinsipyo kung saan nakabatay ang REST.
Sa pangalawa, isasaalang-alang namin kung paano nangyayari ang komunikasyon sa pagitan ng isang kliyente at server sa pamamagitan ng HTTP protocol.
Sa pangatlo, magsusulat kami ng isang maliit na RESTful na application na aming susubukan gamit ang isang program na tinatawag na "Postman".
Ang artikulo ay inilaan para sa mga mambabasa na pamilyar sa mga sumusunod na termino:
HTTP
URL at URI
JSON at (sa mas mababang lawak) XML
Dependency injection
Part 1. Ano ang REST?
Ang REST, tulad ng marami sa mundo ng IT, ay isang acronym. Ito ay nagmula sa "Representational State Transfer" . Ito ay isang istilong arkitektura para sa pakikipag-ugnayan sa pagitan ng mga bahagi ng isang distributed system sa isang computer network. Sa madaling salita, tinutukoy ng REST ang istilo para sa pakikipag-ugnayan (pagpapalitan ng data) sa pagitan ng iba't ibang bahagi ng system, na ang bawat isa ay maaaring pisikal na matatagpuan sa iba't ibang lugar. Ang istilong arkitektura na ito ay isang pare-parehong hanay ng mga hadlang na sinusunod kapag nagdidisenyo ng isang distributed system. Ang mga hadlang na ito ay tinatawag na mga gabay na prinsipyo ng REST. Hindi marami, 6 lang. Mamaya na lang natin sila pag-usapan.
Ang mga application na binuo na nasa isip ang mga prinsipyo ng REST, ibig sabihin, ang mga hindi lumalabag sa mga hadlang sa REST, ay tinatawag na "RESTful".
Kasaysayan ng REST
Ang terminong REST ay ipinakilala ni Roy Fielding, isa sa mga tagalikha ng HTTP protocol, sa kanyang Ph.D. thesis na pinamagatang "Mga Estilo ng Arkitektura at Disenyo ng Mga Arkitektura ng Software na nakabatay sa Network" noong 2000. Bagama't matatawag pa ring bata ang terminong REST, ang konseptong kinakatawan nito ay nasa pinakabuod ng World Wide Web. Hindi tayo sisisid sa kasaysayan ng termino. Kung gusto mong sumisid sa mga pangunahing mapagkukunan, tingnan ang disertasyon ni Fielding .
Mga hadlang at prinsipyo ng REST
Gaya ng nakasaad sa itaas, tinutukoy ng REST kung paano dapat makipag-ugnayan ang mga bahagi ng isang distributed system sa isa't isa. Sa pangkalahatan, nangyayari ito sa pamamagitan ng proseso ng paghiling-tugon. Ang component na nagpapadala ng kahilingan ay tinatawag na client , at ang component na nagpoproseso ng kahilingan at nagpapadala ng tugon sa client ay tinatawag na server. Ang mga kahilingan at tugon ay kadalasang ipinapadala sa pamamagitan ng HTTP protocol. Ang HTTP ay nangangahulugang HyperText Transfer Protocol. Karaniwan, ang isang server ay ilang web application. Ang kliyente ay maaaring halos kahit ano. Halimbawa, isang mobile app na humihiling ng data mula sa isang server. O isang browser na nagpapadala ng mga kahilingan mula sa isang web page patungo sa isang server upang mag-download ng data. Maaaring humiling ng data ang Application A mula sa Application B. Sa kasong ito, ang A ay isang kliyente na may kinalaman sa B, at ang B ay isang server na may kinalaman sa A. Kasabay nito, maaaring iproseso ng A ang mga kahilingan mula sa B, C, D, atbp. Sa kasong ito, ang application A ay parehong server at kliyente. Ang lahat ay nakasalalay sa konteksto. Isang bagay ang tiyak: ang bahagi na nagpapadala ng kahilingan ay ang kliyente. Ang bahagi na tumatanggap, nagpoproseso at tumutugon sa isang kahilingan ay ang server. gayunpaman, hindi lahat ng system na ang mga bahagi ay nakikipag-usap sa pamamagitan ng proseso ng paghiling-tugon ay isang RESTful system. Para maituring na RESTful ang isang system, dapat itong sumunod sa anim na limitasyon ng REST:
1. Arkitektura ng Client-server
Ang paghihigpit na ito ay tungkol sa paghihiwalay ng mga alalahanin. Kinakailangang paghiwalayin ang mga kinakailangan ng interface ng kliyente mula sa mga kinakailangan ng server na nag-iimbak ng data. Ang paghihigpit na ito ay ginagawang mas portable ang client code sa iba pang mga platform, at ang pagpapasimple sa panig ng server ay nagpapabuti sa scalability ng system. Ang paggawa ng pagkakaiba sa pagitan ng "kliyente" at "server" ay nagbibigay-daan sa kanila na mabuo nang hiwalay sa isa't isa.
2. Stateless
Ang isang RESTful na arkitektura ay nangangailangan ng mga sumusunod na kundisyon upang matugunan. Sa panahon sa pagitan ng mga kahilingan, hindi dapat mag-imbak ang server ng impormasyon tungkol sa estado ng kliyente at vice versa. Ang lahat ng mga kahilingan mula sa kliyente ay dapat na binubuo sa paraang nagbibigay sa server ng lahat ng kinakailangang impormasyon upang makumpleto ang kahilingan. Kaya, parehong ang server at ang kliyente ay maaaring "maunawaan" ang anumang natanggap na mensahe, nang hindi umaasa sa mga nakaraang mensahe.
3. Nai-cache
Maaaring i-cache ng mga kliyente ang mga tugon ng server. Ang mga ito, sa turn, ay dapat na tahasan o hindi malinaw na italaga bilang naka-cache o hindi naka-cache, upang ang mga kliyente ay hindi makatanggap ng luma o hindi tamang data bilang tugon sa mga kasunod na kahilingan. Ang wastong pag-cache ay nakakatulong na ganap o bahagyang maalis ang ilang mga pakikipag-ugnayan ng client-server, higit pang pataasin ang performance ng system at scalability.
4. Unipormeng interface
Kasama sa mga pangunahing kinakailangan ng isang RESTful na arkitektura ang isang pinag-isang, pare-parehong interface. Dapat palaging maunawaan ng kliyente ang format at mga address na kailangan nitong gamitin kapag nagpapadala ng kahilingan, at dapat ding maunawaan ng server ang format na dapat nitong gamitin kapag tumutugon sa mga kahilingan ng kliyente. Ang pare-parehong pakikipag-ugnayan ng client-server na naglalarawan kung ano, saan, sa anong anyo, at kung paano magpadala ng data ay isang pinag-isang interface.
5. Mga layer
Sa pamamagitan ng mga layer, ang ibig naming sabihin ay ang hierarchical na istraktura ng network. Minsan ang isang kliyente ay maaaring direktang makipag-usap sa server, at kung minsan ito ay nakikipag-ugnayan lamang sa isang intermediate node. Maaaring mapataas ng paggamit ng mga intermediate server ang scalability salamat sa load balancing at distributed caching. Magbigay tayo ng isang halimbawa. Isipin ang isang mobile app na sikat sa buong mundo. Isang mahalagang bahagi ng app ang nagsasangkot ng paglo-load ng mga larawan. Milyon-milyon ang bilang ng mga user nito, kaya hindi kayang hawakan ng isang server ang ganoong kabigat na load. Ang paghihiwalay ng system sa mga layer ay malulutas ang problemang ito. Kung ang kliyente ay humiling ng isang larawan mula sa isang intermediate node, pagkatapos ay ang intermediate na node ay humihiling ng larawan mula sa server na hindi gaanong na-load sa ngayon at ibinabalik ang larawan sa kliyente. Kung wastong inilapat ang caching sa bawat antas ng hierarchy,
6. Code on demand (opsyonal)
Ang paghihigpit na ito ay nagpapahiwatig na ang kliyente ay maaaring palawakin ang paggana nito sa pamamagitan ng pag-download ng code mula sa server sa anyo ng mga applet o script.
Mga kalamangan ng isang RESTful na arkitektura
Ang mga application na sumusunod sa lahat ng nabanggit na mga hadlang ay may mga sumusunod na pakinabang: pagiging maaasahan (hindi na kailangang i-save ang estado ng kliyente, na maaaring mawala)
pagganap (dahil sa paggamit ng cache)
scalability
transparent na komunikasyon
mga simpleng interface
maaaring dalhin
kakayahang gumawa ng mga pagbabago nang madali
kakayahang umunlad at umangkop sa mga bagong pangangailangan
Hahatiin namin ang aming pangkalahatang-ideya ng REST sa tatlong bahagi:
