Gambaran keseluruhan REST. Bahagian 1: Apakah itu REST?

Hai! Hari ini kita akan belajar tentang topik yang sangat menarik dan, yang paling penting, dalam permintaan tinggi dalam pasaran buruh: REHAT. Kami akan membahagikan gambaran keseluruhan REST kami kepada tiga bahagian:

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

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

3. Dalam ketiga, kami akan menulis aplikasi RESTful kecil yang akan kami uji menggunakan program yang dipanggil "Postman".

Artikel ini ditujukan untuk pembaca yang biasa dengan istilah berikut:

• HTTP
• URL dan URI
• JSON dan (sedikit sebanyak) XML
• Suntikan kebergantungan

Bahagian 1. Apakah itu REHAT?

REST, seperti juga dalam dunia IT, ialah akronim. Ia berasal daripada "Pemindahan Negara Perwakilan" . Ini ialah gaya seni bina untuk interaksi antara komponen sistem teragih dalam rangkaian komputer. Ringkasnya, REST menentukan gaya untuk interaksi (bertukar data) antara komponen sistem yang berbeza, setiap satunya boleh ditempatkan secara fizikal di tempat yang berbeza. Gaya seni bina ini ialah satu set kekangan yang konsisten yang dipatuhi semasa mereka bentuk sistem teragih. Kekangan ini kadangkala dipanggil prinsip panduan REST. Tidak banyak, hanya 6. Kita akan bercakap tentang mereka sedikit kemudian.

Sejarah REHAT

Istilah REST diperkenalkan oleh Roy Fielding, salah seorang pencipta protokol HTTP, dalam Ph.D. tesis bertajuk "Gaya Senibina dan Reka Bentuk Seni Bina Perisian Berasaskan Rangkaian" pada tahun 2000. Walaupun istilah REST masih boleh dipanggil muda, konsep yang diwakilinya terletak pada teras World Wide Web. Kami tidak akan menyelami sejarah istilah tersebut. Jika anda ingin menyelami sumber utama, lihat disertasi Fielding .

kekangan 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 proses permintaan-tindak balas. Komponen yang menghantar permintaan dipanggil klien , dan komponen yang memproses permintaan dan menghantar respons kepada klien dipanggil pelayan. Permintaan dan respons paling kerap dihantar melalui protokol HTTP. HTTP adalah singkatan dari HyperText Transfer Protocol. Biasanya, pelayan adalah beberapa aplikasi web. Pelanggan boleh menjadi hampir apa sahaja. 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. Dalam kes ini, A ialah pelanggan berkenaan dengan B, dan B ialah pelayan berkenaan dengan A. Pada masa yang sama, A boleh memproses permintaan daripada B, C, D, dsb. Dalam kes ini, aplikasi A ialah pelayan dan pelanggan. Semuanya bergantung pada konteks. Satu perkara yang pasti: komponen yang menghantar permintaan ialah klien. Komponen yang menerima, memproses dan bertindak balas kepada permintaan ialah pelayan. Walau bagaimanapun, bukan setiap sistem yang komponennya berkomunikasi melalui proses permintaan-tindak balas adalah sistem RESTful. Untuk sistem dianggap RESTful, ia mesti mematuhi enam kekangan REST:

1. Seni bina pelayan-pelanggan

Kekangan ini adalah mengenai pengasingan kebimbangan. Ia adalah perlu untuk memisahkan keperluan antara muka klien daripada keperluan pelayan yang menyimpan data. Kekangan ini menjadikan kod pelanggan lebih mudah alih ke platform lain, dan memudahkan bahagian pelayan meningkatkan kebolehskalaan sistem. Membuat perbezaan antara "klien" dan "pelayan" membolehkan mereka dibangunkan secara bebas antara satu sama lain.

2. Tanpa kewarganegaraan

Seni bina RESTful memerlukan syarat berikut untuk dipenuhi. Dalam tempoh antara permintaan, pelayan tidak boleh menyimpan maklumat tentang keadaan klien dan sebaliknya. Semua permintaan daripada pelanggan mesti disusun dengan cara yang memberikan pelayan semua maklumat yang diperlukan untuk melengkapkan permintaan. Oleh itu, kedua-dua pelayan dan pelanggan boleh "memahami" sebarang mesej yang diterima, tanpa bergantung pada mesej sebelumnya.

3. Boleh dicache

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

4. Antara muka seragam

Keperluan asas seni bina RESTful termasuk antara muka seragam yang bersatu. Pelanggan mesti sentiasa memahami format dan alamat yang perlu digunakan semasa menghantar permintaan, dan pelayan, seterusnya, mesti juga memahami format yang sepatutnya digunakan semasa membalas permintaan pelanggan. Interaksi pelanggan-pelayan yang konsisten ini yang menerangkan apa, di mana, dalam bentuk apa dan cara menghantar data ialah antara muka bersatu.

5. Lapisan

Dengan lapisan, kami maksudkan struktur hierarki rangkaian. Kadangkala pelanggan boleh berkomunikasi secara langsung dengan pelayan, dan kadangkala ia hanya berkomunikasi dengan nod perantaraan. Penggunaan pelayan perantaraan boleh meningkatkan kebolehskalaan terima kasih kepada pengimbangan beban dan caching teragih. Mari kita berikan contoh. Bayangkan aplikasi mudah alih yang popular di seluruh dunia. Bahagian penting apl melibatkan memuatkan gambar. Penggunanya berjumlah berjuta-juta, jadi satu pelayan tidak dapat menangani beban yang begitu berat. Mengasingkan sistem kepada lapisan akan menyelesaikan masalah ini. Jika klien meminta gambar daripada nod perantaraan, maka nod perantaraan meminta gambar daripada pelayan yang paling kurang dimuatkan pada masa ini dan mengembalikan gambar kepada klien. Jika caching digunakan dengan betul pada setiap peringkat hierarki,

6. Kod atas permintaan (pilihan)

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

Kelebihan seni bina RESTful

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

• prestasi (disebabkan oleh penggunaan cache)
• kebolehskalaan
• komunikasi yang telus
• antara muka yang mudah
• mudah alih
• keupayaan untuk membuat perubahan dengan mudah
• keupayaan untuk berkembang dan menyesuaikan diri dengan keperluan baru

Gambaran keseluruhan REST. Bahagian 2: Komunikasi antara klien dan pelayan Gambaran Keseluruhan REST. Bahagian 3: Membina perkhidmatan RESTful pada Spring Boot