Pangkalahatang-ideya ng REST. Part 1: Ano ang REST

Kumusta, ngayon ay pag-aaralan natin ang isang napaka-kawili-wili, at pinaka-mahalaga, in-demand na paksa sa merkado ng paggawa - REST. Hahatiin namin ang pangkalahatang-ideya ng REST sa tatlong bahagi:

1. Sa unang bahagi, tatalakayin natin ang kasaysayan ng REST at ilalarawan ang mga prinsipyo kung saan nakabatay ang REST.

2. Sa pangalawa, titingnan natin kung paano nangyayari ang komunikasyon sa pagitan ng kliyente at server sa pamamagitan ng HTTP protocol.

3. Sa pangatlo, magsusulat kami ng isang maliit na RESTful application, na susuriin namin gamit ang Postman program.

Ang artikulo ay inilaan para sa isang mambabasa na pamilyar sa mga sumusunod na termino:

• HTTP;
• URL at URI;
• JSON at sa mas maliit na sukat ng XML;
• Dependency Injection.

Part 1. Ano ang REST

Ang REST, tulad ng maraming bagay sa mundo ng IT, ay isang acronym para sa Representational State Transfer . Ito ay isang istilo ng arkitektura ng pakikipag-ugnayan sa pagitan ng mga distributed system component sa isang computer network. Sa madaling salita, tinutukoy ng REST ang isang istilo ng pakikipag-ugnayan (pagpapalitan ng data) sa pagitan ng iba't ibang bahagi ng isang system, na ang bawat isa ay maaaring pisikal na matatagpuan sa iba't ibang lugar. Ang istilong arkitektura na ito ay kumakatawan sa isang pare-parehong hanay ng mga hadlang na isinasaalang-alang kapag nagdidisenyo ng isang distributed system. Ang mga paghihigpit na ito ay tinatawag na mga prinsipyo ng REST. Hindi naman marami, 6 pieces lang. Pag-uusapan natin sila mamaya.

Kasaysayan ng REST

Ang terminong REST ay nilikha ni Roy Fielding, isa sa mga tagalikha ng HTTP protocol, sa kanyang disertasyong doktoral na "Mga Estilo ng Arkitektura at Disenyo ng Mga Arkitektura ng Software na nakabatay sa Network" noong 2000. Masasabi nating bata pa ang terminong REST, bagama't ang konsepto nito ay nasa pinakabatayan ng World Wide Web. Hindi tayo sumisid nang malalim sa kasaysayan ng pinagmulan ng terminong ito. Kung gusto mong sumisid sa mga orihinal na mapagkukunan, tingnan ang disertasyon ni Fielding .

Mga paghihigpit 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, ito ay nangyayari sa pamamagitan ng kahilingan-tugon. Ang sangkap na nagpapadala ng kahilingan ay tinatawag na kliyente ; Ang sangkap na nagpoproseso ng kahilingan at nagpapadala ng tugon sa kliyente ay tinatawag na server . Ang mga kahilingan at tugon ay kadalasang ipinapadala sa pamamagitan ng HTTP (HyperText Transfer Protocol). Karaniwan, ang isang server ay isang uri ng web application. Ang kliyente ay maaaring hindi lamang kahit ano, ngunit medyo marami. Halimbawa, isang mobile application na humihiling ng data mula sa server. O isang browser na nagpapadala ng mga kahilingan mula sa isang web page patungo sa isang server upang mag-download ng data. Ang Application A ay maaaring humiling ng data mula sa application B. Pagkatapos ay ang A ay isang kliyente na may kaugnayan sa B, at ang B ay isang server na may kaugnayan sa A. Kasabay nito, ang A ay maaaring magproseso ng mga kahilingan mula sa C, D, D, atbp. Sa kasong ito, ang application A ay parehong server at kliyente. Ang lahat ay nakasalalay sa konteksto. Isang bagay ang malinaw: ang bahagi na nagpapadala ng kahilingan ay ang kliyente. Ang bahagi na tumatanggap, nagpoproseso at tumutugon sa kahilingan ay ang server. Gayunpaman, hindi lahat ng system na ang mga bahagi ay nakikipag-usap sa pamamagitan ng kahilingan-tugon ay isang REST (o RESTful) na sistema. Para maituring na RESTful ang isang system, dapat itong "magkasya" sa anim na limitasyon ng REST:

1. Dinadala ang arkitektura sa isang modelo ng client-server

Ang batayan ng limitasyong ito ay ang pagkakaiba-iba ng mga pangangailangan. Kinakailangang paghiwalayin ang mga pangangailangan ng interface ng kliyente mula sa mga pangangailangan ng server na nag-iimbak ng data. Ang limitasyong ito ay nagpapataas ng portability ng client code sa iba pang mga platform, at ang pagpapasimple ng bahagi ng server ay nagpapabuti sa scalability ng system. Ang mismong pagkakaiba sa pagitan ng "kliyente" at "server" ay nagbibigay-daan sa kanila na bumuo nang nakapag-iisa sa isa't isa.

2. Kakulangan ng kondisyon

Ang arkitektura ng REST ay nangangailangan ng sumusunod na kundisyon upang matugunan. Sa pagitan ng mga kahilingan, hindi kailangan ng server na mag-imbak ng impormasyon tungkol sa estado ng kliyente at vice versa. Ang lahat ng mga kahilingan mula sa kliyente ay dapat na nakaayos upang matanggap ng server ang lahat ng kinakailangang impormasyon upang makumpleto ang kahilingan. Sa ganitong paraan, maaaring "maunawaan" ng server at ng kliyente ang anumang mensaheng natanggap nang hindi umaasa sa mga naunang mensahe.

3. Pag-cache

Maaaring i-cache ng mga kliyente ang mga tugon ng server. Ang mga ito, sa turn, ay dapat na tahasan o tuwirang itinalaga bilang cacheable o uncacheable, upang ang mga kliyente ay hindi makatanggap ng lipas o maling data bilang tugon sa mga kasunod na kahilingan. Ang wastong paggamit ng caching ay nakakatulong na maalis ang ilang mga pakikipag-ugnayan ng client-server, ganap o bahagyang, higit pang pagpapataas ng performance at pagpapalawak ng system.

4. Pagkakapareho ng interface

Kasama sa mga pangunahing kinakailangan ng REST architecture ang isang pinag-isang interface. Dapat palaging maunawaan ng kliyente kung anong format at kung aling mga address ang kailangan nitong magpadala ng kahilingan, at dapat ding maunawaan ng server kung anong format ang dapat nitong tumugon sa mga kahilingan ng kliyente. Ito ay isang pinag-isang format para sa pakikipag-ugnayan ng client-server, na naglalarawan kung ano, saan, sa anong anyo at kung paano ipapadala at ito ay isang pinag-isang interface

5. Mga layer

Ang mga layer ay tumutukoy sa hierarchical na istraktura ng mga network. Minsan ang kliyente ay maaaring makipag-usap nang direkta sa server, at kung minsan ay maaari lamang itong makipag-usap sa isang intermediate node. Maaaring mapataas ng paggamit ng mga intermediate server ang scalability sa pamamagitan ng load balancing at distributed caching. Magbigay tayo ng halimbawa. Isipin natin ang isang mobile application na sikat sa buong mundo. Ang mahalagang bahagi nito ay ang paglo-load ng mga larawan. Dahil mayroong milyon-milyong mga gumagamit, ang isang server ay hindi makayanan ang ganoong kabigat na pagkarga. Ang paghahati ng system sa mga layer ay malulutas ang problemang ito. Hihiling ang kliyente ng larawan mula sa intermediate node, hihilingin ng intermediate node ang larawan mula sa server na hindi gaanong na-load sa ngayon, at ibabalik ang larawan sa kliyente. Kung ang pag-cache ay inilapat nang tama dito sa bawat antas ng hierarchy, kung gayon ang mahusay na scalability ng system ay maaaring makamit.

6. Code on demand (opsyonal na paghihigpit)

Ang limitasyong ito ay nagpapahiwatig na maaaring palawakin ng kliyente ang pagpapagana nito sa pamamagitan ng pag-download ng code mula sa server sa anyo ng mga applet o script.

Ang mga benepisyo ng REST

Ang mga application na sumusunod sa lahat ng mga paghihigpit sa itaas ay may mga sumusunod na pakinabang: pagiging maaasahan (hindi na kailangang mag-imbak ng impormasyon ng estado ng kliyente, na maaaring mawala);

• pagganap (dahil sa paggamit ng cache);
• scalability;
• transparency ng sistema ng pakikipag-ugnayan;
• pagiging simple ng mga interface;
• maaaring dalhin ng mga bahagi;
• kadalian ng paggawa ng mga pagbabago;
• ang kakayahang mag-evolve, umangkop sa mga bagong pangangailangan.

Part 2: komunikasyon sa pagitan ng client at server Part 3: paggawa ng isang RESTful service sa Spring Boot