Ringkesan REST. Part 2: Komunikasi antarane klien lan server

Ringkesan REST. Part 1: Apa REST? Ing bagean iki, kita bakal nyilem babagan cara komunikasi antarane klien lan server. Sadawane dalan, kita bakal nemokake istilah anyar lan nerangake. Kanggo mesthekake yen kabeh wis jelas, kita bakal nganalisa komunikasi klien-server nggunakake aplikasi RESTful minangka conto. Upaminipun kita ngembangaken aplikasi web sing nyimpen informasi babagan pelanggan lan pesenan. Ing tembung liya, sistem kita bisa nindakake operasi ing entitas tartamtu: nggawe, ngowahi, lan mbusak, lan nampilake informasi babagan entitas kasebut. Entitas kasebut bakal dadi:

• pelanggan (pelanggan)
• pesenan (pesanan pelanggan)
• item (produk)

Ing arsitektur RESTful, klien ngirim panjalukan menyang server kanggo njupuk utawa ngowahi data, banjur server ngirim respon klien marang panjaluke.

Njaluk

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

• metode HTTP
• header
• URI
• njaluk awak

Ing ngisor iki kita bakal nimbang saben komponen kanthi luwih rinci.

URI lan sumber daya

Data sing ditampa utawa diowahi klien liwat panjalukan diarani sumber daya. Komunikasi klien-server kabeh babagan manipulasi sumber daya. Ing REST, sumber daya yaiku apa wae sing bisa dijenengi. Ing pangertèn, padha kaya kelas ing Jawa. Ing Jawa, kita bisa nggawe kelas kanggo apa wae. Dadi ing REST, sumber bisa apa wae: pangguna, dokumen, laporan, pesenan. Bisa uga minangka abstraksi saka sawetara entitas, utawa sing spesifik, contone, gambar, video, animasi, utawa file PDF. Ing conto kita, kita duwe 3 sumber daya:

• pelanggan (pelanggan)
• pesenan (pesanan pelanggan)
• item (produk)

Klien ngirim panjalukan menyang lokasi sumber daya sing dikenal minangka titik pungkasan. Cukup, endpoint kaya alamat ing jaringan. Nyilem luwih jero, kita bisa ujar manawa titik pungkasan yaiku URI, yaiku urutan karakter sing ngenali sumber abstrak utawa fisik. Uniform resource identifier (URI) Kadhangkala endpoint, utawa URI, diarani path, tegese path menyang sumber. Kanggo tujuan artikel iki, kita bakal nggunakake istilah URI. Saben sumber daya tartamtu kudu duwe URI unik. Pangembang server tanggung jawab kanggo mesthekake yen saben sumber mesthi nduweni URI dhewe. Ing conto kita, kita minangka pangembang, mula kita bakal nindakake kanthi cara sing kita ngerti. Kaya biasane kanggo nemtokake pengenal numerik minangka kunci utama ing basis data relasional, saben sumber uga duwe ID dhewe ing REST. ID sumber daya ing REST asring cocog karo ID rekaman ing database sing nyimpen informasi babagan sumber daya. URI REST biasane diwiwiti kanthi bentuk jamak saka tembung sing njlèntrèhaké sawetara sumber. Tuladhane, "

• / pelanggan - URI kabeh pelanggan sing kasedhiya
• / pelanggan / 23 - URI saka pelanggan tartamtu, yaiku pelanggan kanthi ID = 23
• / pelanggan / 4 - URI saka pelanggan tartamtu, yaiku pelanggan kanthi ID = 4.

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

• / pelanggan / 4 / pesenan - URI kabeh pesenan digawe dening customer No
• / pelanggan / 1 / pesenan / 12 - URI pesenan No.. 12 digawe dening customer No.. 1.

Yen kita nerusake ekspansi kanthi nambahake luwih akeh produk, kita entuk:

• / pelanggan / 1 / pesenan / 12 / item - URI dhaptar kabeh produk ing urutan No.. 12 digawe dening customer No.. 1.

Nalika kita nambah tingkat nesting, sing penting yaiku nggawe URI intuisi.

metode HTTP

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

• GET - Entuk informasi babagan sumber daya tartamtu (liwat ID) utawa babagan koleksi sumber daya
• POST - Nggawe sumber daya anyar
• PUT - Ngganti sumber daya (liwat ID sawijining)
• Mbusak - Mbusak sumber daya (liwat ID sawijining)

Headers

Panjaluk, uga tanggapan, ngemot header HTTP. Padha ngirim informasi tambahan babagan panjalukan (utawa respon). Header minangka pasangan kunci-nilai. Sampeyan bisa ndeleng dhaptar header sing paling umum ing Wikipedia . Kanggo REST, klien asring ngirim header "Nampa" ing panjalukan menyang server. Header iki dibutuhake kanggo ngandhani server format apa sing dikarepake klien bakal nampa respon. Macem-macem format diwenehi ing dhaptar jinis MIME. MIME (Multipurpose Internet Mail Extensions) minangka spesifikasi kanggo informasi enkoding lan format pesen supaya bisa dikirim liwat Internet. Saben jinis MIME kasusun saka rong bagéan sing 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

Contone, panjalukan bisa duwe header kaya iki:

Accept:application/json

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

Njaluk awak

Iki minangka pesen sing dikirim dening klien menyang server. Apa panjaluk kasebut nduweni awak utawa ora gumantung saka jinis panjalukan HTTP. Contone, panjalukan GET lan DELETE umume ora ngemot badan panyuwunan. Nanging panjaluk PUT lan POST bisa - mung gumantung saka tujuan panjaluk kasebut. Sawise kabeh, kanggo nampa lan / utawa mbusak data nggunakake ID (sing diterusake ing URL), sampeyan ora perlu ngirim data tambahan menyang server. Nanging kanggo nggawe sumber daya anyar (liwat request POST), sampeyan kudu ngirim sumber. Padha bener kanggo ngowahi sumber daya sing ana. Ing REST, badan panyuwunan paling kerep dikirim ing format XML utawa JSON. Format JSON paling umum. Upaminipun kita arep ngirim panjalukan kanggo server kanggo nggawe sumber anyar. Yen sampeyan ora lali, kita dianggep conto aplikasi sing ngatur pesenan customer. Ayo, kita pengin nggawe pelanggan anyar. Ing kasus kita, kita nyimpen informasi pelanggan ing ngisor iki: Jeneng, email, nomer telpon. Banjur awak panyuwunan bisa dadi JSON ing ngisor iki:

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

Nggawe panjalukan bebarengan

Dadi, kita wis nliti apa sing ana ing panjaluk klien. Saiki kita bakal menehi sawetara conto panjalukan bebarengan karo deskripsi

Tanggapan

Ayo ngomong sawetara tembung babagan respon server. Tanggapan 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 tanggapan lan panjaluk. Aku kabeh uga cetha babagan badan request. Awak asring ngasilake informasi sing dijaluk klien. Informasi sing bali kanggo nanggepi panjalukan GET bisa uga ana ing format JSON. Nanging bagean pungkasan luwih menarik.

Kode respon HTTP

Ayo dipikirake kode respon HTTP kanthi luwih rinci. Kode status HTTP minangka bagéan saka baris pisanan respon server kanggo panjalukan sing digawe liwat protokol HTTP. Iki minangka integer sing dumadi saka telung digit desimal. Digit pisanan nuduhake kelas kode status respon. Kode respon biasane diiringi frasa panjelasan ing basa Inggris, dipisahake karo spasi. Frasa iki minangka alesan sing bisa diwaca manungsa kanggo nanggepi. Tuladha:

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

Kode respon ngandhani klien asil saka panjalukan lan ngidini kanggo nemtokake tumindak apa sabanjuré. Kode respon dipérang dadi sawetara kelas utawa klompok:

• 1XX - Informasi
• 2XX — Kode iki nuduhake yen panjalukan klien wis kasil ditampa lan diproses
• 3XX - Kode kasebut ngandhani klien manawa panjaluk tambahan, biasane menyang URI sing beda, kudu ditindakake supaya bisa ngrampungake operasi kasebut.
• 4XX - Kesalahan klien. Kode kasebut bisa uga amarga panyuwunan sing salah. Conto liyane yaiku kode "404 Not Found" sing kondhang, sing bisa kedadeyan nalika klien njaluk sumber daya sing ora ana.
• 5XX - kesalahan server. Kode iki bali menyang klien yen server tanggung jawab kanggo Gagal operasi

Ringkesan REST. Part 3: Nggawe layanan RESTful ing Spring Boot