Pangkalahatang-ideya ng REST. Bahagi 2: Komunikasyon sa pagitan ng isang kliyente at server

Pangkalahatang-ideya ng REST. Part 1: Ano ang REST? Sa bahaging ito, susuriin natin nang malalim kung paano nagaganap ang komunikasyon sa pagitan ng isang kliyente at server. Sa daan, aalisin namin ang mga bagong termino at ipapaliwanag ang mga ito. Upang matiyak na malinaw ang lahat, susuriin namin ang komunikasyon ng client-server gamit ang isang RESTful na application bilang isang halimbawa. Ipagpalagay na gumagawa kami ng isang web application na nag-iimbak ng impormasyon tungkol sa mga customer at kanilang mga order. Sa madaling salita, nagagawa ng aming system ang mga operasyon sa ilang partikular na entity: lumikha, mag-edit, at magtanggal ng mga ito, at magpakita ng impormasyon tungkol sa kanila. Ang mga entity na ito ay magiging:

• mga customer (mga customer)
• mga order (mga order ng customer)
• item (mga produkto)

Sa isang RESTful architecture, ang mga kliyente ay nagpapadala ng mga kahilingan sa isang server upang kunin o baguhin ang data, at pagkatapos ay ang mga server ay magpapadala ng mga tugon sa mga kliyente sa kanilang mga kahilingan.

Mga kahilingan

Ang mga kahilingan ng kliyente ay halos palaging ginagawa gamit ang HTTP protocol. Sa pangkalahatan, ang mga kahilingan sa HTTP ay binubuo ng ilang bahagi:

• pamamaraan ng HTTP
• header
• URI
• humiling ng katawan

Sa ibaba ay isasaalang-alang namin ang bawat bahagi nang mas detalyado.

Mga URI at mapagkukunan

Ang data na natatanggap o binago ng mga kliyente sa pamamagitan ng mga kahilingan ay tinatawag na mga mapagkukunan. Ang komunikasyon ng kliyente-server ay tungkol sa pagmamanipula ng mga mapagkukunan. Sa REST, ang mga mapagkukunan ay anumang bagay na maaari mong bigyan ng pangalan. Sa isang kahulugan, sila ay tulad ng mga klase sa Java. Sa Java, maaari tayong lumikha ng isang klase para sa anumang bagay. Kaya sa REST, ang isang mapagkukunan ay maaaring maging anuman: isang gumagamit, isang dokumento, isang ulat, isang order. Maaari itong maging abstraction ng ilang entity, o isang partikular na bagay, halimbawa, isang imahe, video, animation, o PDF file. Sa aming halimbawa, mayroon kaming 3 mapagkukunan:

• mga customer (mga customer)
• mga order (mga order ng customer)
• item (mga produkto)

Nagpapadala ang mga kliyente ng mga kahilingan sa mga lokasyon ng mapagkukunan na kilala bilang mga endpoint. Sa madaling salita, ang isang endpoint ay parang isang address sa network. Sa pagsisid nang mas malalim, masasabi nating ang isang endpoint ay isang URI, ibig sabihin, isang pagkakasunod-sunod ng mga character na tumutukoy sa abstract o pisikal na mapagkukunan. Uniform resource identifier (URI) Minsan ang isang endpoint, o URI, ay tinatawag na path, ibig sabihin ang path patungo sa isang mapagkukunan. Para sa mga layunin ng artikulong ito, gagamitin namin ang terminong URI. Ang bawat partikular na mapagkukunan ay dapat may natatanging URI. Responsable ang developer ng server sa pagtiyak na ang bawat mapagkukunan ay palaging may sariling URI. Sa aming halimbawa, kami ang mga nag-develop, kaya gagawin namin ito sa paraang alam namin kung paano. Tulad ng madalas na kaugalian na magtalaga ng mga numerical identifier bilang pangunahing mga key sa isang relational database, ang bawat mapagkukunan ay mayroon ding sariling ID sa REST. Ang resource ID sa REST ay madalas na tumutugma sa ID ng record sa database na nag-iimbak ng impormasyon tungkol sa resource. Ang mga REST URI ay karaniwang nagsisimula sa plural na anyo ng isang pangngalan na naglalarawan ng ilang mapagkukunan. Halimbawa, "

• /customers — URI ng lahat ng available na customer
• /customers/23 — URI ng isang partikular na customer, ibig sabihin, ang customer na may ID=23
• /customers/4 — URI ng isang partikular na customer, ibig sabihin, ang customer na may ID=4.

Ngunit hindi lang iyon. Maaari naming palawigin ang URI sa pamamagitan ng pagdaragdag ng mga order:

• /customers/4/orders — URI ng lahat ng order na ginawa ng customer No. 4
• /customers/1/orders/12 — URI ng order No. 12 na ginawa ng customer No. 1.

Kung ipagpapatuloy namin ang pagpapalawak sa pamamagitan ng pagdaragdag ng higit pang mga produkto, makakakuha kami ng:

• /customers/1/orders/12/item — URI ng listahan ng lahat ng produkto sa order No. 12 na ginawa ng customer No. 1.

Habang nagdaragdag kami ng mga antas ng nesting, ang mahalagang bagay ay gawing intuitive ang mga URI.

pamamaraan ng HTTP

Ang pamamaraan ng HTTP ay isang pagkakasunud-sunod ng anumang mga character (maliban sa mga control character at delimiter), na nagpapahiwatig ng pangunahing operasyon na ginagawa sa mapagkukunan. Mayroong ilang mga karaniwang pamamaraan ng HTTP. Ililista namin ang mga pinakamadalas na ginagamit sa mga serbisyong RESTful:

• GET — Kumuha ng impormasyon tungkol sa isang partikular na mapagkukunan (sa pamamagitan ng ID nito) o tungkol sa isang koleksyon ng mga mapagkukunan
• POST — Lumikha ng bagong mapagkukunan
• PUT — Baguhin ang isang mapagkukunan (sa pamamagitan ng ID nito)
• DELETE — Magtanggal ng mapagkukunan (sa pamamagitan ng ID nito)

Mga header

Ang mga kahilingan, pati na rin ang mga tugon, ay naglalaman ng mga header ng HTTP. Naghahatid sila ng karagdagang impormasyon tungkol sa kahilingan (o tugon). Ang mga header ay key-value pairs. Maaari mong tingnan ang listahan ng mga pinakakaraniwang header sa Wikipedia . Tulad ng para sa REST, ang mga kliyente ay madalas na nagpapadala ng isang "Tanggapin" na header sa mga kahilingan sa server. Ang header na ito ay kinakailangan upang sabihin sa server kung anong format kung saan inaasahan ng kliyente na makatanggap ng tugon. Ang iba't ibang mga format ay ibinibigay sa isang listahan ng mga uri ng MIME. Ang MIME (Multipurpose Internet Mail Extensions) ay isang detalye para sa pag-encode ng impormasyon at pag-format ng mga mensahe upang maipadala ang mga ito sa Internet. Ang bawat uri ng MIME ay binubuo ng dalawang bahagi na pinaghihiwalay ng isang slash — isang uri at subtype. Mga halimbawa ng mga uri ng MIME para sa iba't ibang uri ng mga file:

• text — text/plain, text/css, text/html
• larawan — larawan/png, larawan/jpeg, larawan/gif
• audio — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• application — application/json, application/pdf, application/xml, application/octet-stream

Halimbawa, ang isang kahilingan ay maaaring magkaroon ng header na tulad nito:

Accept:application/json

Sinasabi ng header na ito sa server na inaasahan ng kliyente na makatanggap ng tugon sa format na JSON.

Humiling ng katawan

Ito ang mensaheng ipinadala ng kliyente sa server. Kung ang kahilingan ay may katawan o wala ay depende sa uri ng kahilingan sa HTTP. Halimbawa, ang mga kahilingan sa GET at DELETE ay karaniwang hindi naglalaman ng anumang nilalaman ng kahilingan. Ngunit ang mga kahilingan sa PUT at POST ay maaaring — depende lang ito sa layunin ng kahilingan. Pagkatapos ng lahat, upang makatanggap at/o magtanggal ng data gamit ang isang ID (na ipinasa sa URL), hindi mo kailangang magpadala ng karagdagang data sa server. Ngunit upang makalikha ng bagong mapagkukunan (sa pamamagitan ng isang kahilingan sa POST), kailangan mong ipadala ang mapagkukunan. Ang parehong ay totoo para sa pagbabago ng isang umiiral na mapagkukunan. Sa REST, ang nilalaman ng kahilingan ay madalas na ipinadala sa XML o JSON na format. Ang format ng JSON ay pinakakaraniwan. Ipagpalagay na gusto naming magpadala ng isang kahilingan sa server upang lumikha ng isang bagong mapagkukunan. Kung hindi mo pa nakakalimutan, isinasaalang-alang namin ang halimbawa ng isang application na namamahala sa mga order ng customer. Sabihin nating gusto naming lumikha ng bagong customer. Sa aming kaso, iniimbak namin ang sumusunod na impormasyon ng customer: Pangalan, email, numero ng telepono. Kung gayon ang katawan ng kahilingan ay maaaring ang sumusunod na JSON:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Pinagsasama-sama ang mga kahilingan

Kaya, napagmasdan namin kung ano ang maaaring nasa kahilingan ng kliyente. Magbibigay kami ngayon ng ilang halimbawa ng mga kahilingan kasama ang mga paglalarawan

Mga tugon

Magsabi tayo ng ilang salita tungkol sa mga tugon ng server. Ang tugon ay karaniwang binubuo ng mga sumusunod na bahagi:

• code ng tugon
• mga header
• katawan ng tugon

Sa pangkalahatan, ang mga header ng tugon ay hindi gaanong naiiba sa mga header ng kahilingan. Bilang karagdagan, ang ilang mga header ay ginagamit sa parehong mga tugon at kahilingan. Sa tingin ko malinaw din ang lahat tungkol sa request body. Ang katawan ay madalas na nagbabalik ng impormasyon na hiniling ng kliyente. Ang impormasyong ibinalik bilang tugon sa mga kahilingan sa GET ay maaari ding nasa JSON na format. Ngunit ang huling bahagi ay medyo mas kawili-wili.

Mga code ng tugon ng HTTP

Isaalang-alang natin ang mga HTTP response code nang mas detalyado. Ang isang HTTP status code ay bahagi ng unang linya ng tugon ng server sa mga kahilingang ginawa sa pamamagitan ng HTTP protocol. Ito ay isang integer na binubuo ng tatlong decimal na digit. Ang unang digit ay nagpapahiwatig ng klase ng code ng status ng tugon. Ang sagot na code ay karaniwang sinusundan ng isang paliwanag na parirala sa Ingles, na pinaghihiwalay ng isang puwang. Ang pariralang ito ay nababasa ng tao na dahilan para sa pagtugon. Mga halimbawa:

• 201 Nilikha
• 401 Hindi awtorisado
• 507 Hindi Sapat na Imbakan

Sinasabi ng code ng tugon sa kliyente ang resulta ng kahilingan at pinapayagan itong matukoy kung anong mga aksyon ang susunod na gagawin. Ang mga response code ay nahahati sa ilang mga klase o grupo:

• 1XX — Pang-impormasyon
• 2XX — Isinasaad ng mga code na ito na matagumpay na natanggap at naproseso ang kahilingan ng kliyente
• 3XX — Ang mga code na ito ay nagpapaalam sa kliyente na ang isang karagdagang kahilingan, kadalasan sa ibang URI, ay dapat gawin upang matagumpay na makumpleto ang operasyon
• 4XX — Error sa kliyente. Ang ganitong mga code ay maaaring magresulta mula sa isang maling pagkakabuo ng kahilingan. Ang isa pang halimbawa ay ang kilalang "404 Not Found" code, na maaaring mangyari kapag humiling ang isang kliyente ng hindi umiiral na mapagkukunan.
• 5XX — Error sa server. Ang mga code na ito ay ibinalik sa kliyente kung ang server ay may pananagutan sa pagkabigo ng operasyon

Pangkalahatang-ideya ng REST. Bahagi 3: Pagbuo ng isang RESTful na serbisyo sa Spring Boot