Gambaran keseluruhan REST. Bahagian 1: Apa itu REHAT

Halo, hari ini kita akan mengkaji topik yang sangat menarik, dan yang paling penting, dalam permintaan dalam pasaran buruh - REST. Kami akan memecahkan gambaran keseluruhan REST kepada tiga bahagian:

1. Pada bahagian pertama, kami akan menyentuh sejarah REST dan menerangkan prinsip yang menjadi asas REST.

2. Dalam yang kedua, kita akan melihat bagaimana komunikasi berlaku antara klien dan pelayan melalui protokol HTTP.

3. Pada yang ketiga, kami akan menulis aplikasi RESTful kecil, yang akan kami uji menggunakan program Postman.

Artikel ini ditujukan untuk pembaca yang biasa dengan istilah berikut:

• HTTP;
• URL dan URI;
• JSON dan sedikit sebanyak XML;
• Suntikan Ketergantungan.

Bahagian 1. Apa itu REHAT

REST, seperti banyak perkara dalam dunia IT, ialah akronim untuk Representational State Transfer . Ini ialah gaya seni bina interaksi antara komponen sistem teragih dalam rangkaian komputer. Ringkasnya, REST mentakrifkan gaya interaksi (pertukaran data) antara komponen sistem yang berbeza, setiap satunya mungkin terletak secara fizikal di tempat yang berbeza. Gaya seni bina ini mewakili set kekangan yang konsisten yang dipertimbangkan semasa mereka bentuk sistem teragih. Sekatan ini kadangkala dipanggil prinsip REST. Tak banyak pun cuma 6 biji sahaja. Kita akan bercakap tentang mereka sedikit kemudian.

Sejarah REHAT

Istilah REST dicipta oleh Roy Fielding, salah seorang pencipta protokol HTTP, dalam disertasi kedoktorannya "Gaya Senibina dan Reka Bentuk Seni Bina Perisian Berasaskan Rangkaian" pada tahun 2000. Kita boleh mengatakan bahawa istilah REST masih muda, walaupun konsepnya terletak pada asas World Wide Web. Kami tidak akan menyelami sejarah asal usul istilah ini. Jika anda ingin menyelami sumber asal, lihat disertasi Fielding .

Sekatan dan prinsip REST

Seperti yang dinyatakan di atas, REST mentakrifkan bagaimana komponen sistem teragih harus berinteraksi antara satu sama lain. Secara umum, ini berlaku melalui permintaan-tindak balas. Komponen yang menghantar permintaan dipanggil klien ; Komponen yang memproses permintaan dan menghantar respons kepada klien dipanggil pelayan . Permintaan dan respons paling kerap dihantar melalui HTTP (HyperText Transfer Protocol). Biasanya, pelayan adalah sejenis aplikasi web. Pelanggan boleh bukan apa-apa sahaja, tetapi agak banyak. Contohnya, aplikasi mudah alih yang meminta data daripada pelayan. Atau penyemak imbas yang menghantar permintaan daripada halaman web ke pelayan untuk memuat turun data. Aplikasi A boleh meminta data daripada aplikasi B. Kemudian A ialah klien berhubung dengan B, dan B ialah pelayan berhubung dengan A. Pada masa yang sama, A boleh memproses permintaan daripada C, D, D, dsb. Dalam kes ini, aplikasi A ialah pelayan dan pelanggan. Semuanya bergantung pada konteks. Satu perkara yang jelas: komponen yang menghantar permintaan ialah pelanggan. Komponen yang menerima, memproses dan bertindak balas kepada permintaan ialah pelayan. Walau bagaimanapun, bukan setiap sistem yang komponennya berkomunikasi melalui permintaan-tindak balas adalah sistem REST (atau RESTful). Untuk sistem dianggap RESTful, ia mesti "memastikan" enam kekangan REST:

1. Membawa seni bina kepada model pelayan-pelanggan

Asas batasan ini ialah pembezaan keperluan. Ia adalah perlu untuk memisahkan keperluan antara muka klien daripada keperluan pelayan yang menyimpan data. Had ini meningkatkan kemudahalihan kod klien ke platform lain, dan penyederhanaan bahagian pelayan meningkatkan kebolehskalaan sistem. Perbezaan antara "klien" dan "pelayan" membolehkan mereka berkembang secara bebas antara satu sama lain.

2. Kekurangan keadaan

Seni bina REST memerlukan syarat berikut untuk dipenuhi. Di antara permintaan, pelayan tidak perlu menyimpan maklumat tentang keadaan klien dan sebaliknya. Semua permintaan daripada pelanggan mesti distrukturkan supaya pelayan menerima semua maklumat yang diperlukan untuk melengkapkan permintaan. Dengan cara ini, kedua-dua pelayan dan pelanggan boleh "memahami" sebarang mesej yang diterima tanpa bergantung pada mesej sebelumnya.

3. Caching

Pelanggan boleh cache jawapan pelayan. Ini, seterusnya, mesti secara eksplisit atau tersirat ditetapkan sebagai boleh cache atau tidak boleh cache, supaya pelanggan tidak menerima data lapuk atau salah sebagai tindak balas kepada permintaan berikutnya. Penggunaan caching yang betul membantu menghapuskan beberapa interaksi pelayan-pelanggan, sepenuhnya atau sebahagian, meningkatkan lagi prestasi dan kebolehlanjutan sistem.

4. Keseragaman antara muka

Keperluan asas seni bina REST termasuk antara muka yang bersatu dan konsisten. Pelanggan mesti sentiasa memahami dalam format apa dan alamat mana yang ia perlukan untuk menghantar permintaan, dan pelayan, seterusnya, mesti juga memahami dalam format apa ia harus bertindak balas kepada permintaan pelanggan. Ini ialah format bersatu untuk interaksi pelanggan-pelayan, yang menerangkan apa, di mana, dalam bentuk apa dan cara menghantar dan merupakan antara muka bersatu

5. Lapisan

Lapisan merujuk kepada struktur hierarki rangkaian. Kadang-kadang pelanggan boleh berkomunikasi secara langsung dengan pelayan, dan kadang-kadang ia hanya boleh berkomunikasi dengan nod perantaraan. Penggunaan pelayan perantaraan boleh meningkatkan kebolehskalaan melalui pengimbangan beban dan caching teragih. Mari kita beri contoh. Mari bayangkan aplikasi mudah alih yang popular di seluruh dunia. Bahagian pentingnya ialah memuatkan imej. Memandangkan terdapat berjuta-juta pengguna, satu pelayan tidak dapat menahan beban yang begitu berat. Membahagikan sistem kepada lapisan akan menyelesaikan masalah ini. Pelanggan akan meminta gambar daripada nod perantaraan, nod perantaraan akan meminta gambar daripada pelayan yang paling kurang dimuatkan pada masa ini, dan akan mengembalikan gambar itu kepada klien. Jika caching digunakan dengan betul di sini pada setiap peringkat hierarki, maka skalabiliti sistem yang baik boleh dicapai.

6. Kod atas permintaan (sekatan pilihan)

Had ini membayangkan bahawa pelanggan boleh mengembangkan fungsinya dengan memuat turun kod daripada pelayan dalam bentuk applet atau skrip.

Faedah REHAT

Aplikasi yang mematuhi semua sekatan di atas mempunyai kelebihan berikut: kebolehpercayaan (tidak perlu menyimpan maklumat keadaan pelanggan, yang mungkin hilang);

• prestasi (disebabkan oleh penggunaan cache);
• kebolehskalaan;
• ketelusan sistem interaksi;
• kesederhanaan antara muka;
• mudah alih komponen;
• kemudahan membuat perubahan;
• keupayaan untuk berkembang, menyesuaikan diri dengan keperluan baru.

Bahagian 2: komunikasi antara pelanggan dan pelayan Bahagian 3: mencipta perkhidmatan RESTful dalam Spring Boot