Gambaran keseluruhan REST. Bahagian 2: Komunikasi antara pelanggan dan pelayan

Gambaran keseluruhan REST. Bahagian 1: Apakah itu REST? Dalam bahagian ini, kita akan menyelami cara komunikasi berlaku antara pelanggan dan pelayan. Sepanjang perjalanan, kami akan mendedahkan istilah baharu dan menerangkannya. Untuk memastikan semuanya jelas, kami akan menganalisis komunikasi pelanggan-pelayan menggunakan aplikasi RESTful sebagai contoh. Katakan kita sedang membangunkan aplikasi web yang menyimpan maklumat tentang pelanggan dan pesanan mereka. Dalam erti kata lain, sistem kami dapat melaksanakan operasi pada entiti tertentu: mencipta, mengedit dan memadamkannya serta memaparkan maklumat tentang entiti tersebut. Entiti ini akan menjadi:

• pelanggan (pelanggan)
• pesanan (pesanan pelanggan)
• barang (produk)

Dalam seni bina RESTful, pelanggan menghantar permintaan kepada pelayan untuk mendapatkan semula atau mengubah suai data, dan kemudian pelayan menghantar respons pelanggan kepada permintaan mereka.

Permintaan

Permintaan pelanggan hampir selalu dibuat menggunakan protokol HTTP. Secara umum, permintaan HTTP terdiri daripada beberapa komponen:

• kaedah HTTP
• kepala
• URI
• badan permintaan

Di bawah ini kami akan mempertimbangkan setiap komponen dengan lebih terperinci.

URI dan sumber

Data yang pelanggan terima atau ubah suai melalui permintaan dipanggil sumber. Komunikasi pelanggan-pelayan adalah mengenai memanipulasi sumber. Dalam REST, sumber ialah apa sahaja yang anda boleh beri nama. Dari satu segi, mereka seperti kelas di Jawa. Di Java, kita boleh membuat kelas untuk apa sahaja. Jadi dalam REST, sumber boleh menjadi apa sahaja: pengguna, dokumen, laporan, pesanan. Ia boleh sama ada abstraksi beberapa entiti, atau sesuatu yang khusus, contohnya, imej, video, animasi atau fail PDF. Dalam contoh kami, kami mempunyai 3 sumber:

• pelanggan (pelanggan)
• pesanan (pesanan pelanggan)
• barang (produk)

Pelanggan menghantar permintaan ke lokasi sumber yang dikenali sebagai titik akhir. Ringkasnya, titik akhir adalah seperti alamat pada rangkaian. Menyelam lebih dalam, kita boleh mengatakan bahawa titik akhir ialah URI, iaitu urutan aksara yang mengenal pasti sumber abstrak atau fizikal. Pengecam sumber seragam (URI) Kadangkala titik akhir, atau URI, dipanggil laluan, bermaksud laluan ke sumber. Untuk tujuan artikel ini, kami akan menggunakan istilah URI. Setiap sumber tertentu mesti mempunyai URI unik. Pembangun pelayan bertanggungjawab untuk memastikan setiap sumber sentiasa mempunyai URI sendiri. Dalam contoh kami, kami adalah pembangun, jadi kami akan melakukannya dengan cara yang kami tahu. Sama seperti kebiasaan untuk menetapkan pengecam berangka sebagai kunci utama dalam pangkalan data hubungan, setiap sumber juga mempunyai ID sendiri dalam REST. ID sumber dalam REST selalunya sepadan dengan ID rekod dalam pangkalan data yang menyimpan maklumat tentang sumber tersebut. URI REST biasanya bermula dengan bentuk jamak kata nama yang menerangkan beberapa sumber. Sebagai contoh, "

• /customers — URI semua pelanggan yang tersedia
• /customers/23 — URI pelanggan tertentu, iaitu pelanggan dengan ID=23
• /customers/4 — URI pelanggan tertentu, iaitu pelanggan dengan ID=4.

Tetapi bukan itu sahaja. Kami boleh melanjutkan URI dengan menambah pesanan:

• /customers/4/orders — URI semua pesanan yang dibuat oleh pelanggan No. 4
• /pelanggan/1/pesanan/12 — URI pesanan No. 12 yang dibuat oleh pelanggan No. 1.

Jika kami meneruskan pengembangan dengan menambah lebih banyak produk, kami mendapat:

• /customers/1/orders/12/items — URI senarai semua produk dalam pesanan No. 12 yang dibuat oleh pelanggan No. 1.

Semasa kami menambah tahap sarang, perkara penting ialah menjadikan URI intuitif.

kaedah HTTP

Kaedah HTTP ialah jujukan mana-mana aksara (kecuali aksara kawalan dan pembatas), yang menunjukkan operasi utama sedang dilakukan pada sumber. Terdapat beberapa kaedah HTTP biasa. Kami akan menyenaraikan yang paling kerap digunakan dalam perkhidmatan RESTful:

• GET — Dapatkan maklumat tentang sumber tertentu (melalui IDnya) atau tentang koleksi sumber
• POST — Buat sumber baharu
• PUT — Tukar sumber (melalui IDnya)
• PADAM — Padamkan sumber (melalui IDnya)

Pengepala

Permintaan, serta respons, mengandungi pengepala HTTP. Mereka menyampaikan maklumat tambahan tentang permintaan (atau respons). Pengepala ialah pasangan nilai kunci. Anda boleh melihat senarai tajuk yang paling biasa di Wikipedia . Bagi REST, pelanggan sering menghantar pengepala "Terima" dalam permintaan kepada pelayan. Pengepala ini diperlukan untuk memberitahu pelayan format yang klien jangkakan untuk menerima respons. Pelbagai format diberikan dalam senarai jenis MIME. MIME (Sambungan Mel Internet Serbaguna) ialah spesifikasi untuk pengekodan maklumat dan memformatkan mesej supaya ia boleh dihantar melalui Internet. Setiap jenis MIME terdiri daripada dua bahagian yang dipisahkan oleh garis miring — jenis dan subjenis. Contoh jenis MIME untuk jenis fail yang berbeza:

• teks — teks/biasa, teks/css, teks/html
• imej — imej/png, imej/jpeg, imej/gif
• audio — audio/wav, audio/mpeg
• video — video/mp4, video/ogg
• aplikasi — application/json, application/pdf, application/xml, application/octet-stream

Sebagai contoh, permintaan boleh mempunyai pengepala seperti ini:

Accept:application/json

Pengepala ini memberitahu pelayan bahawa klien menjangkakan menerima respons dalam format JSON.

Badan permintaan

Ini adalah mesej yang dihantar oleh klien kepada pelayan. Sama ada permintaan itu mempunyai badan atau tidak bergantung pada jenis permintaan HTTP. Sebagai contoh, permintaan GET dan DELETE secara amnya tidak mengandungi sebarang badan permintaan. Tetapi permintaan PUT dan POST boleh — ia hanya bergantung pada tujuan permintaan. Lagipun, untuk menerima dan/atau memadam data menggunakan ID (yang dihantar dalam URL), anda tidak perlu menghantar data tambahan ke pelayan. Tetapi untuk mencipta sumber baharu (melalui permintaan POST), anda perlu menghantar sumber tersebut. Perkara yang sama berlaku untuk mengubah suai sumber sedia ada. Dalam REST, badan permintaan paling kerap dihantar dalam format XML atau JSON. Format JSON adalah yang paling biasa. Katakan kita mahu menghantar permintaan kepada pelayan untuk mencipta sumber baharu. Jika anda tidak lupa, kami mempertimbangkan contoh aplikasi yang menguruskan pesanan pelanggan. Katakan kami ingin mencipta pelanggan baharu. Dalam kes kami, kami menyimpan maklumat pelanggan berikut: Nama, e-mel, nombor telefon. Kemudian badan permintaan itu boleh menjadi JSON berikut:

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

Menyatukan permintaan

Jadi, kami telah meneliti perkara yang mungkin ada dalam permintaan pelanggan. Kami kini akan memberikan beberapa contoh permintaan bersama dengan penerangan

Jawapan

Katakan beberapa perkataan tentang respons pelayan. Respons biasanya terdiri daripada bahagian berikut:

• kod tindak balas
• tajuk
• badan tindak balas

Secara umum, pengepala respons tidak jauh berbeza daripada pengepala permintaan. Selain itu, beberapa pengepala digunakan dalam kedua-dua respons dan permintaan. Saya rasa semuanya juga jelas mengenai badan permintaan. Badan sering mengembalikan maklumat yang diminta oleh pelanggan. Maklumat yang dikembalikan sebagai respons kepada permintaan GET mungkin juga dalam format JSON. Tetapi bahagian terakhir adalah sedikit lebih menarik.

Kod respons HTTP

Mari kita pertimbangkan kod respons HTTP dengan lebih terperinci. Kod status HTTP ialah sebahagian daripada baris pertama respons pelayan kepada permintaan yang dibuat melalui protokol HTTP. Ia adalah integer yang terdiri daripada tiga digit perpuluhan. Digit pertama menunjukkan kelas kod status respons. Kod respons biasanya diikuti dengan frasa penjelasan dalam bahasa Inggeris, dipisahkan oleh ruang. Frasa ini adalah sebab yang boleh dibaca manusia untuk respons. Contoh:

• 201 Dicipta
• 401 Tanpa kebenaran
• 507 Storan Tidak Mencukupi

Kod respons memberitahu pelanggan hasil permintaan dan membolehkannya menentukan tindakan yang perlu diambil seterusnya. Kod respons dibahagikan kepada beberapa kelas atau kumpulan:

• 1XX — Bermaklumat
• 2XX — Kod ini menunjukkan bahawa permintaan pelanggan telah berjaya diterima dan diproses
• 3XX — Kod ini memberitahu pelanggan bahawa permintaan tambahan, biasanya kepada URI yang berbeza, mesti dibuat untuk berjaya menyelesaikan operasi
• 4XX — Ralat pelanggan. Kod sedemikian mungkin terhasil daripada permintaan yang tidak betul. Contoh lain ialah kod "404 Not Found" yang terkenal, yang boleh berlaku apabila pelanggan meminta sumber yang tidak wujud
• 5XX — Ralat pelayan. Kod ini dikembalikan kepada klien jika pelayan bertanggungjawab atas kegagalan operasi

Gambaran keseluruhan REST. Bahagian 3: Membina perkhidmatan RESTful pada Spring Boot