Ringkesan REST. Part 2: Komunikasi antarane klien lan server

Part 1: Apa REST Ing bagean iki kita bakal nliti cara komunikasi antarane klien lan server. Sadawane dalan, kita bakal mbukak istilah anyar lan menehi panjelasan. Kanggo nggawe kabeh (dadi) cetha, kita bakal nganalisa komunikasi klien-server nggunakake conto sawetara aplikasi RESTful. Contone, kita ngembangake aplikasi web sing bisa nyimpen informasi babagan pelanggan lan pesenan. Sing. sistem kita bisa ngapusi sawetara entitas: nggawe, nyunting, mbusak, lan menehi informasi babagan. Entitas kasebut bakal dadi:

• klien - klien;
• pesenan - pesenan pelanggan;
• barang - barang.

Ing arsitektur REST, klien ngirim panjalukan menyang server kanggo njupuk utawa ngowahi data, lan server ngirim respon menyang klien kanggo panjaluke.

Njaluk

Panjaluk klien meh tansah digawe liwat HTTP. Umumé, panjalukan HTTP kalebu sawetara komponen:

• cara HTTP;
• judhul;
• URI;
• njaluk awak.

Ing ngisor iki kita bakal nliti saben bagean komponen kanthi luwih rinci.

URI lan Sumber Daya

Data sing ditampa utawa diowahi klien liwat panjalukan diarani sumber daya. Basis interaksi klien-server yaiku manipulasi sumber daya. Sumber daya ing REST yaiku apa wae sing bisa diwenehi jeneng. Ing pangertèn, iki kaya kelas ing Jawa. Ing Jawa kita bisa nggawe kelas kanggo apa wae. Iku padha ing REST - sumber bisa apa wae: pangguna, dokumen, laporan, pesenan. Kabeh iki bisa uga minangka abstraksi saka sawetara entitas utawa soko konkrit, contone, file - gambar, video, animasi, file PDF. Contone, kita duwe 3 sumber daya:

• klien - klien;
• pesenan - pesenan pelanggan;
• barang - barang.

Klien ngirim panjalukan menyang titik pungkasan, utawa titik pungkasan. Gampang banget, endpoint kaya alamat ing jaringan. Kanggo luwih jero, titik pungkasan yaiku URI : urutan karakter sing ngenali sumber abstrak utawa fisik. Uniform Resource Identifier - pengenal sumber daya manunggal. Kadhangkala titik pungkasan, utawa URI, diarani path - path menyang sumber daya. Kanggo tujuan artikel iki, kita bakal nggunakake istilah URI. Saben sumber daya tartamtu kudu duwe URI unik. Tanggung jawab kanggo mesthekake yen saben sumber tansah nduweni URI dhewe dumunung ing pundhak pangembang server. Ing conto kita, kita minangka pangembang, mula kita bakal nindakake kanthi cara sing kita ngerti. Kaya ing basis data relasional, biasane nyetel kunci utama menyang ID numerik tartamtu, ing REST saben sumber duwe ID dhewe. Asring kedadeyan yen ID sumber ing REST cocog karo ID rekaman ing database sing informasi babagan sumber iki disimpen. REST URI biasane diwiwiti kanthi bentuk jamak saka tembung sing nggambarake sawetara sumber. Contone, saka tembung klien. Sabanjure, ID dituduhake liwat garis miring - pengenal klien tartamtu. Tuladha:

• / klien - URI kabeh klien sing ana;
• /clients/23 - URI saka klien tartamtu, yaiku klien karo ID=23;
• /clients/4 - URI saka klien tartamtu, yaiku klien karo ID=4.

Nanging ora mung kuwi. Kita bisa ngluwihi URI kanthi nambahake pesenan kasebut:

• /clients/4/orders — URI kabeh pesenan klien No.
• / klien / 1 / pesenan / 12 - URI pesenan No.. 12 saka klien No.. 1.

Yen kita nerusake rantai iki lan nambah barang, kita entuk:

• /clients/1/orders/12/item — URI saka dhaptar kabeh produk ing urutan No.. 12 digawe dening klien No.. 1.

Kanthi level nesting, kuncine yaiku nggawe URI intuisi.

metode HTTP

Metode HTTP (Metode HTTP Inggris) minangka urutan karakter apa wae, kajaba kontrol lan separator, sing nuduhake operasi utama ing sumber daya. Ana sawetara cara HTTP umum. Kita dhaptar sing paling asring digunakake ing layanan RESTful:

• GET - digunakake kanggo njupuk informasi babagan sumber daya tartamtu (liwat ID) utawa koleksi sumber;
• POST - digunakake kanggo nggawe sumber anyar;
• PUT - digunakake kanggo ngganti sumber daya (liwat ID);
• DELETE - digunakake kanggo mbusak sumber daya (liwat ID).

Judhul

Panjaluk, uga tanggapan, ngemot header HTTP. Padha ngirim informasi tambahan babagan panjalukan (utawa respon). Header minangka pasangan kunci-nilai. Sampeyan bisa maca dhaptar judhul sing paling umum ing kaca Wikipedia . Kanthi REST, klien asring bisa ngirim header Tampa ing panjaluke menyang server. Sampeyan perlu supaya server ngerti ing format apa klien ngarepake kanggo nampa respon saka iku. Macem-macem opsi format ditampilake ing dhaptar jinis MIME sing disebut. MIME (Multipurpose Internet Mail Extensions) minangka spesifikasi kanggo enkoding informasi lan format pesen supaya bisa dikirim liwat Internet. Saben jinis MIME kasusun saka rong bagéan, dipisahake kanthi garis miring: jinis lan subtipe. Conto jinis MIME kanggo macem-macem jinis file:

• teks - teks / polos, teks / css, teks / html;
• gambar - gambar/png, gambar/jpeg, gambar/gif;
• audio - audio / wav, audio / mpeg;
• video - video / mp4, video / ogg;
• aplikasi - application/json, application/pdf, application/xml, application/octet-stream.

Secara total, panjalukan kasebut bisa duwe header ing ngisor iki:

Accept:application/json

Header iki ngandhani server yen klien ngarepake nampa respon ing format JSON.

Njaluk awak

Pesen sing dikirim dening klien menyang server. Apa panjaluk duwe awak utawa ora gumantung saka jinis panjalukan HTTP. Contone, panjalukan GET lan DELETE biasane ora ngemot badan panjaluk. Nanging PUT lan POST bisa ngemot: kabeh babagan tujuan fungsional saka jinis panyuwunan. Sawise kabeh, kanggo nampa data lan mbusak kanthi id (sing dikirim ing URL), sampeyan ora perlu ngirim data tambahan menyang server. Nanging kanggo nggawe sumber daya anyar (POST request), sampeyan kudu nransfer sumber daya iki. Semono uga kanggo ngowahi sumber daya sing ana. Ing REST, format XML utawa JSON paling kerep digunakake kanggo ngirim badan panyuwunan. Format paling umum yaiku JSON. Upaminipun kita arep ngirim panjalukan kanggo server, lan ing nggawe sumber anyar. Yen sampeyan ngelingi, minangka conto, kita ndeleng aplikasi sing ngatur pesenan pelanggan. Ayo, kita pengin nggawe klien anyar. Ing kasus kita, kita nyimpen informasi ing ngisor iki babagan klien: Jeneng Email Nomer telpon Banjur awak panjaluk kasebut bisa dadi JSON ing ngisor iki:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

Nggawe panjalukan bebarengan

Dadi, kita wis ndeleng apa panjaluk klien bisa kalebu. Ayo saiki menehi sawetara conto pitakon kanthi deskripsi

Wangsulan

Ayo ngomong sawetara tembung babagan respon server. Jawaban biasane kasusun saka bagean ing ngisor iki:

• kode respon;
• header;
• awak respon.

Umumé, header respon ora beda karo header panjaluk. Kajaba iku, sawetara header digunakake ing respon lan panjaluk. Aku kabeh wis jelas karo awak respon banget. Awak asring ngasilake informasi sing dijaluk klien. Informasi bisa dibalekake ing format JSON sing padha kanggo panjaluk GET. Nanging bagean pungkasan luwih menarik.

Kode respon HTTP

Ayo dideleng kanthi luwih cetha babagan kode respon HTTP. Punika kutipan saka Wikipedia: Kode status HTTP minangka bagéan saka baris pisanan saka respon server kanggo panjalukan liwat protokol HTTP. Iki minangka integer kanthi telung digit desimal. Digit pisanan nuduhake kelas kondisi. Kode respon biasane ngiring dening frase panjelasan ing basa Inggris dipisahake dening spasi, kang nerangake kanggo wong alesan kanggo respon tartamtu iki. Tuladha:

• 201 Digawe;
• 401 Ora sah;
• 507 Panyimpenan ora cukup.

Klien sinau saka kode respon babagan asil panjaluke lan nemtokake tindakan sing bakal ditindakake sabanjure. Kode respon dipérang dadi sawetara klompok:

• 1ХХ - informasi;
• 2ХХ - ngandhani babagan kasus nampa sukses lan ngolah panjaluk klien;
• 3XX - ngandhani klien yen supaya bisa ngrampungake operasi kasebut, perlu nggawe panyuwunan liyane, biasane nggunakake URI sing beda;
• 4ХХ - kesalahan klien. Contone, panjalukan sing salah dibangun utawa kode 404 Not Found sing kondhang, sing bisa kedadeyan nalika klien njaluk sumber daya sing ora ana;
• 5ХХ - kesalahan server. Bali menyang klien yen operasi gagal amarga fault saka server.

Sampeyan bisa maca liyane babagan kabeh kode kene . Part 1: Apa REST Part 3: Nggawe layanan RESTful ing Spring Boot