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

Bahagian 1: Apakah itu REST Dalam bahagian ini kita akan melihat dengan lebih dekat bagaimana komunikasi berlaku antara klien dan pelayan. Sepanjang perjalanan, kami akan mendedahkan istilah baharu dan memberi penjelasan untuknya. Untuk menjadikan semuanya (menjadi) jelas, kami akan menganalisis komunikasi pelanggan-pelayan menggunakan contoh beberapa aplikasi RESTful. Katakan kami sedang membangunkan aplikasi web yang mampu menyimpan maklumat tentang pelanggan dan pesanan mereka. Itu. sistem kami mampu memanipulasi beberapa entiti: menciptanya, mengeditnya, memadamkannya dan memberikan maklumat tentangnya. Entiti ini akan menjadi:

• pelanggan - pelanggan;
• pesanan - pesanan pelanggan;
• barang - barang.

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

Permintaan

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

• kaedah HTTP;
• tajuk;
• URI;
• badan permintaan.

Di bawah ini kita akan melihat setiap bahagian komponen dengan lebih terperinci.

URI dan Sumber

Data yang pelanggan peroleh atau ubah suai melalui permintaan dipanggil sumber. Asas interaksi pelanggan-pelayan adalah manipulasi sumber. Sumber dalam REST ialah apa sahaja yang boleh diberi nama. Dari satu segi, ini adalah seperti kelas di Jawa. Di Jawa kita boleh membuat kelas untuk apa sahaja. Ia sama dalam REST - sumber boleh terdiri daripada apa sahaja: pengguna, dokumen, laporan, pesanan. Semua ini boleh menjadi sama ada abstraksi beberapa entiti atau sesuatu yang konkrit, sebagai contoh, fail - gambar, video, animasi, fail PDF. Untuk contoh kami, kami mempunyai 3 sumber:

• pelanggan - pelanggan;
• pesanan - pesanan pelanggan;
• barang - barang.

Pelanggan menghantar permintaan kepada apa yang dipanggil titik akhir, atau titik akhir. Secara ringkasnya, titik akhir adalah seperti alamat pada rangkaian. Untuk lebih mendalam, titik akhir ialah URI : jujukan aksara yang mengenal pasti sumber abstrak atau fizikal. Pengecam Sumber Seragam - pengecam sumber bersatu. Kadangkala titik akhir, atau URI, dipanggil laluan - laluan ke sumber. Untuk tujuan artikel ini, kami akan menggunakan istilah URI. Setiap sumber tertentu mesti mempunyai URI unik. Tanggungjawab untuk memastikan setiap sumber sentiasa mempunyai URI sendiri terletak di bahu pembangun pelayan. Dalam contoh kami, kami adalah pembangun, jadi kami akan melakukannya dengan cara yang kami tahu. Sama seperti dalam pangkalan data hubungan, selalunya untuk menetapkan kunci utama kepada ID berangka tertentu, dalam REST setiap sumber mempunyai ID sendiri. Selalunya berlaku bahawa ID sumber dalam REST sepadan dengan ID rekod dalam pangkalan data di mana maklumat tentang sumber ini disimpan. URI REST biasanya bermula dengan bentuk jamak bagi kata nama yang menerangkan beberapa sumber. Contohnya, daripada perkataan pelanggan. Seterusnya, ID ditunjukkan melalui garis miring - pengecam pelanggan tertentu. Contoh:

• /clients - URI semua pelanggan sedia ada;
• /clients/23 - URI klien tertentu, iaitu klien dengan ID=23;
• /clients/4 - URI klien tertentu, iaitu klien dengan ID=4.

Tetapi bukan itu sahaja. Kami boleh memanjangkan URI dengan menambahkan pesanan kepadanya:

• /clients/4/orders — URI semua pesanan pelanggan No. 4;
• /clients/1/orders/12 - URI pesanan No. 12 pelanggan No. 1.

Jika kita meneruskan rantaian ini dan menambah barang, kita mendapat:

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

Dengan tahap bersarang, kuncinya ialah menjadikan URI intuitif.

kaedah HTTP

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

• GET - digunakan untuk mendapatkan maklumat tentang sumber tertentu (melalui ID) atau koleksi sumber;
• POST - digunakan untuk mencipta sumber baharu;
• PUT - digunakan untuk menukar sumber (melalui ID);
• DELETE - digunakan untuk memadam sumber (melalui ID).

Tajuk

Permintaan, serta respons, mengandungi pengepala HTTP. Mereka menghantar maklumat tambahan tentang permintaan (atau respons). Pengepala ialah pasangan nilai kunci. Anda boleh membaca senarai tajuk yang paling biasa di halaman Wikipedia . Dengan REST, pelanggan selalunya boleh menghantar pengepala Terima dalam permintaan mereka kepada pelayan. Ia diperlukan untuk memberitahu pelayan dalam format yang pelanggan harapkan untuk menerima respons daripadanya. Pelbagai pilihan format dibentangkan dalam senarai jenis MIME yang dipanggil. 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, dipisahkan dengan 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.

Secara keseluruhan, permintaan mungkin mempunyai pengepala berikut:

Accept:application/json

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

Badan permintaan

Mesej yang dihantar oleh klien ke pelayan. Sama ada permintaan mempunyai badan atau tidak bergantung pada jenis permintaan HTTP. Contohnya, permintaan GET dan DELETE biasanya tidak mengandungi sebarang badan permintaan. Tetapi PUT dan POST boleh mengandungi: ini semua tentang tujuan fungsi jenis permintaan. Lagipun, untuk menerima data dan memadamkannya dengan id (yang dihantar dalam URL), anda tidak perlu menghantar data tambahan ke pelayan. Tetapi untuk mencipta sumber baharu (permintaan POST), anda perlu memindahkan sumber ini. Perkara yang sama berlaku untuk mengubah suai sumber sedia ada. Dalam REST, format XML atau JSON paling kerap digunakan untuk menghantar badan permintaan. Format yang paling biasa ialah JSON. Katakan kita mahu menghantar permintaan kepada pelayan, dan di dalamnya mencipta sumber baharu. Jika anda masih ingat, sebagai contoh kami melihat aplikasi yang menguruskan pesanan pelanggan. Katakan kita mahu mencipta pelanggan baharu. Dalam kes kami, kami menyimpan maklumat berikut tentang pelanggan: Nama E-mel Nombor telefon Kemudian kandungan permintaan sedemikian boleh menjadi JSON berikut:

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

Menyatukan permintaan

Jadi, kami telah melihat apa yang boleh terdiri daripada permintaan pelanggan. Mari kita berikan beberapa contoh pertanyaan dengan penerangan

Jawapan

Mari sebutkan beberapa perkataan tentang respons pelayan. Jawapan biasanya terdiri daripada bahagian berikut:

• kod jawapan;
• 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 jelas dengan badan respons juga. Badan sering mengembalikan maklumat yang diminta oleh pelanggan. Maklumat boleh dikembalikan dalam format JSON yang sama untuk permintaan GET. Tetapi bahagian terakhir adalah sedikit lebih menarik.

Kod respons HTTP

Mari kita lihat lebih dekat pada kod respons HTTP. Berikut ialah petikan dari Wikipedia: Kod status HTTP ialah sebahagian daripada baris pertama respons pelayan untuk permintaan melalui protokol HTTP. Ia adalah integer dengan tiga digit perpuluhan. Digit pertama menunjukkan kelas keadaan. Kod respons biasanya diikuti dengan frasa penjelasan dalam bahasa Inggeris yang dipisahkan oleh ruang, yang menerangkan kepada orang itu sebab respons khusus ini. Contoh:

• 201 Dicipta;
• 401 Tanpa Kebenaran;
• 507 Storan Tidak Mencukupi.

Pelanggan belajar daripada kod respons tentang hasil permintaannya dan menentukan tindakan yang perlu diambil seterusnya. Kod respons dibahagikan kepada beberapa kumpulan:

• 1ХХ - maklumat;
• 2ХХ - memaklumkan tentang kes penerimaan dan pemprosesan yang berjaya permintaan pelanggan;
• 3XX - maklumkan kepada pelanggan bahawa untuk berjaya menyelesaikan operasi, perlu membuat permintaan lain, biasanya menggunakan URI yang berbeza;
• 4ХХ - ralat pelanggan. Contohnya, permintaan yang tidak dibina dengan betul atau kod 404 Not Found yang terkenal, yang boleh berlaku apabila pelanggan meminta sumber yang tidak wujud;
• 5ХХ - ralat pelayan. Dikembalikan kepada klien jika operasi gagal disebabkan oleh kesalahan pelayan.

Anda boleh membaca lebih lanjut mengenai semua kod di sini . Bahagian 1: Apakah itu REST Bahagian 3: Mencipta perkhidmatan RESTful dalam Spring Boot