JavaRush /Java Blog /Random-TL /Pangkalahatang-ideya ng REST. Bahagi 2: Komunikasyon sa p...

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

Nai-publish sa grupo
Bahagi 1: Ano ang REST Sa bahaging ito ay susuriin natin nang mabuti kung paano nangyayari ang komunikasyon sa pagitan ng kliyente at ng server. Sa daan, magbubunyag kami ng mga bagong termino at magbibigay ng mga paliwanag para sa kanila. Pangkalahatang-ideya ng REST.  Bahagi 2: komunikasyon sa pagitan ng kliyente at server - 1Upang gawing malinaw ang lahat, susuriin namin ang komunikasyon ng client-server gamit ang halimbawa ng ilang RESTful application. Sabihin nating gumagawa kami ng isang web application na may kakayahang mag-imbak ng impormasyon tungkol sa mga customer at kanilang mga order. Yung. ang aming system ay may kakayahang manipulahin ang ilang entity: paglikha sa kanila, pag-edit sa kanila, pagtanggal sa kanila, at pagbibigay ng impormasyon tungkol sa kanila. Ang mga entity na ito ay magiging:
  • mga kliyente - mga kliyente;
  • mga order - mga order ng customer;
  • mga bagay - kalakal.
Sa REST architecture, ang mga kliyente ay nagpapadala ng mga kahilingan sa server upang makakuha o magbago ng data, at ang mga server ay nagpapadala ng mga tugon sa mga kliyente sa kanilang mga kahilingan.

Mga kahilingan

Ang mga kahilingan ng kliyente ay halos palaging ginagawa sa pamamagitan ng HTTP. Sa pangkalahatan, ang mga kahilingan sa HTTP ay binubuo ng ilang bahagi:
  • pamamaraan ng HTTP;
  • pamagat;
  • URI;
  • humiling ng katawan.
Sa ibaba ay titingnan natin ang bawat bahagi ng bahagi nang mas detalyado.

URI at Mga Mapagkukunan

Ang data na nakukuha o binago ng mga kliyente sa pamamagitan ng mga kahilingan ay tinatawag na mga mapagkukunan. Ang batayan ng pakikipag-ugnayan ng client-server ay ang pagmamanipula ng mga mapagkukunan. Ang mga mapagkukunan sa REST ay anumang bagay na maaaring bigyan ng pangalan. Sa isang kahulugan, ang mga ito ay tulad ng mga klase sa Java. Sa Java maaari tayong lumikha ng isang klase para sa anumang bagay. Ito ay pareho sa REST - isang mapagkukunan ay maaaring maging anuman: isang user, isang dokumento, isang ulat, isang order. Ang lahat ng ito ay maaaring alinman sa isang abstraction ng ilang entity o isang bagay na kongkreto, halimbawa, isang file - isang larawan, video, animation, PDF file. Para sa aming halimbawa, mayroon kaming 3 mapagkukunan:
  • mga kliyente - mga kliyente;
  • mga order - mga order ng customer;
  • mga bagay - kalakal.
Nagpapadala ang mga kliyente ng mga kahilingan sa tinatawag na mga endpoint, o mga end point. Upang ilagay ito nang napakasimple, ang isang endpoint ay katulad ng isang address sa network. Upang maging mas malalim, ang isang endpoint ay isang URI : isang pagkakasunud-sunod ng mga character na tumutukoy sa isang abstract o pisikal na mapagkukunan. Uniform Resource Identifier - isang pinag-isang resource identifier. Minsan ang endpoint, o URI, ay tinatawag na isang landas - ang landas 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. Ang responsibilidad para sa pagtiyak na ang bawat mapagkukunan ay palaging may sariling URI ay nakasalalay sa mga balikat ng developer ng server. Sa aming halimbawa, kami ang mga nag-develop, kaya gagawin namin ito sa paraang alam namin kung paano. Tulad ng sa isang relational database kadalasang kaugalian na itakda ang pangunahing susi sa isang tiyak na numerong ID, sa REST bawat mapagkukunan ay may sariling ID. Madalas na nangyayari na ang ID ng isang mapagkukunan sa REST ay tumutugma sa ID ng tala sa database kung saan naka-imbak ang impormasyon tungkol sa mapagkukunang ito. Ang mga REST URI ay karaniwang nagsisimula sa plural na anyo ng isang pangngalan na naglalarawan ng ilang mapagkukunan. Halimbawa, mula sa salitang kliyente. Susunod, ang isang ID ay ipinahiwatig sa pamamagitan ng isang slash - ang identifier ng isang partikular na kliyente. Mga halimbawa:
  • /clients - URI ng lahat ng umiiral na kliyente;
  • /clients/23 - URI ng isang partikular na kliyente, katulad ng kliyente na may ID=23;
  • /clients/4 - URI ng isang partikular na kliyente, katulad ng kliyenteng may ID=4.
Ngunit hindi lang iyon. Maaari naming palawigin ang URI sa pamamagitan ng pagdaragdag ng mga order dito:
  • /clients/4/orders — URI ng lahat ng order ng kliyente No. 4;
  • /clients/1/orders/12 - URI ng order No. 12 ng client No. 1.
Kung ipagpapatuloy namin ang chain na ito at magdagdag ng mga produkto, makakakuha kami ng:
  • /clients/1/orders/12/item — URI ng listahan ng lahat ng produkto sa order No. 12 na ginawa ng kliyente No. 1.
Sa mga antas ng nesting, ang susi ay gawing intuitive ang mga URI.

pamamaraan ng HTTP

Ang HTTP Method (English HTTP Method) ay isang pagkakasunud-sunod ng anumang mga character, maliban sa mga kontrol at separator, na nagpapahiwatig ng pangunahing operasyon sa isang mapagkukunan. Mayroong ilang mga karaniwang pamamaraan ng HTTP. Inilista namin ang mga madalas na ginagamit sa mga serbisyong RESTful:
  • GET - ginagamit upang makakuha ng impormasyon tungkol sa isang partikular na mapagkukunan (sa pamamagitan ng ID) o isang koleksyon ng mga mapagkukunan;
  • POST - ginagamit upang lumikha ng isang bagong mapagkukunan;
  • PUT - ginagamit upang baguhin ang isang mapagkukunan (sa pamamagitan ng ID);
  • DELETE - ginagamit upang tanggalin ang isang mapagkukunan (sa pamamagitan ng ID).

Mga pamagat

Ang mga kahilingan, pati na rin ang mga tugon, ay naglalaman ng mga header ng HTTP. Nagpapadala sila ng karagdagang impormasyon tungkol sa kahilingan (o tugon). Ang mga header ay key-value pairs. Mababasa mo ang listahan ng mga pinakakaraniwang heading sa pahina ng Wikipedia . Sa REST, madalas na maaaring magpadala ang mga kliyente ng Accept header sa kanilang kahilingan sa server. Ito ay kinakailangan upang ipaalam sa server kung anong format ang inaasahan ng kliyente na makatanggap ng tugon mula dito. Ang iba't ibang mga pagpipilian sa format ay ipinakita sa tinatawag na listahan ng 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 isang 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.
Sa kabuuan, maaaring may sumusunod na header ang kahilingan:
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

Isang mensahe na ipinadala ng kliyente sa server. Kung ang isang 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 maaaring maglaman ang PUT at POST: lahat ito ay tungkol sa functional na layunin ng uri ng kahilingan. Pagkatapos ng lahat, upang makatanggap ng data at tanggalin ito sa pamamagitan ng id (na ipinadala sa URL), hindi mo kailangang magpadala ng karagdagang data sa server. Ngunit para gumawa ng bagong resource (POST request), kailangan mong ilipat ang resource na ito. Ang parehong napupunta para sa pagbabago ng isang umiiral na mapagkukunan. Sa REST, ang mga format ng XML o JSON ay kadalasang ginagamit upang ipadala ang katawan ng kahilingan. Ang pinakakaraniwang format ay JSON. Ipagpalagay na gusto naming magpadala ng isang kahilingan sa server, at sa loob nito ay lumikha ng isang bagong mapagkukunan. Kung naaalala mo, bilang isang halimbawa, tiningnan namin ang isang application na namamahala sa mga order ng customer. Sabihin nating gusto naming lumikha ng bagong kliyente. Sa aming kaso, iniimbak namin ang sumusunod na impormasyon tungkol sa mga kliyente: Pangalan Email Numero ng telepono Pagkatapos ang laman ng naturang kahilingan ay maaaring ang sumusunod na JSON:
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

Pinagsasama-sama ang mga kahilingan

Kaya, tiningnan namin kung ano ang maaaring binubuo ng isang kahilingan ng kliyente. Magbigay tayo ngayon ng ilang halimbawa ng mga query na may mga paglalarawan
Hiling Paglalarawan

GET /clients/23
Accept : application/json, application/xml
Kumuha ng impormasyon tungkol sa client No. 23 sa json o xml na format

POST /clients
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}
Lumikha ng bagong kliyente gamit ang mga sumusunod na field:
Pangalan - Amigo
Email - amigo@jr.com
Tel. — +7 (191) 746-43-23

PUT /clients/1
{
  "name" : "Ben",
  "email" : "bigben@jr.com",
  "phone" : "+380 (190) 346-42-13"
}
I-edit ang client #1 bilang sumusunod:
Pangalan - Ben
Email - bigben@jr.com
Tel. — +380 (190) 346-42-13

DELETE /clients/12/orders/6
Tanggalin ang order No. 6 mula sa customer No. 12 mula sa system

Mga sagot

Magsabi tayo ng ilang salita tungkol sa mga tugon ng server. Ang sagot 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 ang lahat ay malinaw din sa katawan ng tugon. Ang katawan ay madalas na nagbabalik ng impormasyon na hiniling ng kliyente. Maaaring ibalik ang impormasyon sa parehong format ng JSON para sa mga kahilingan sa GET. Ngunit ang huling bahagi ay medyo mas kawili-wili.

Mga code ng tugon ng HTTP

Tingnan natin ang mga HTTP response code. Narito ang isang quote mula sa Wikipedia: Ang HTTP status code ay bahagi ng unang linya ng tugon ng server para sa mga kahilingan sa pamamagitan ng HTTP protocol. Ito ay isang integer na may tatlong decimal na digit. Ang unang digit ay nagpapahiwatig ng klase ng kundisyon. Ang sagot na code ay karaniwang sinusundan ng isang paliwanag na parirala sa Ingles na pinaghihiwalay ng isang puwang, na nagpapaliwanag sa tao ng dahilan para sa partikular na tugon na ito. Mga halimbawa:
  • 201 Nilikha;
  • 401 Hindi awtorisado;
  • 507 Hindi Sapat na Imbakan.
Natututo ang kliyente mula sa code ng tugon tungkol sa mga resulta ng kahilingan nito at tinutukoy kung anong mga aksyon ang susunod na gagawin. Ang mga response code ay nahahati sa ilang grupo:
  • 1ХХ - impormasyon;
  • 2ХХ - ipaalam ang tungkol sa mga kaso ng matagumpay na pagtanggap at pagproseso ng kahilingan ng isang kliyente;
  • 3XX - ipaalam sa kliyente na upang matagumpay na makumpleto ang operasyon, kinakailangan na gumawa ng isa pang kahilingan, karaniwang gumagamit ng ibang URI;
  • 4ХХ - error sa kliyente. Halimbawa, isang maling pagkakagawa ng kahilingan o ang kilalang 404 Not Found code, na maaaring mangyari kapag humiling ang isang kliyente ng hindi umiiral na mapagkukunan;
  • 5ХХ - error sa server. Ibinalik sa kliyente kung nabigo ang operasyon dahil sa kasalanan ng server.
Maaari kang magbasa nang higit pa tungkol sa lahat ng mga code dito . Part 1: Ano ang REST Part 3: Paglikha ng isang RESTful na serbisyo sa Spring Boot
Mga komento
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION