Teori API REST

Modul pertama berakhir dengan Anda membuat permintaan HTTP, mengirimnya, dan mendapatkan respons.

Kami akan melakukan ini berkali-kali di masa depan. Kami akan mengirimkan permintaan ke server pihak ketiga. Kami akan membuat aplikasi yang dengan sendirinya menerima permintaan tersebut dan membalasnya. Kami akan membuat logika kompleks untuk memproses permintaan.

Oleh karena itu, akan baik untuk mempelajari secara menyeluruh segala sesuatu yang berkaitan dengan permintaan ini, untuk menganalisisnya secara rinci. Sehingga Anda tidak bisa hanya menyalin permintaan di suatu tempat dan mengulanginya, tetapi benar-benar mencari tahu cara kerjanya.

Inilah yang akan kita lakukan di modul kedua. Ayo pergi!

Teori umum

Mari kita mulai dengan teori.

Jika Anda mengerjakan pekerjaan rumah Anda di modul pertama dan mempelajari dokumentasinya, Anda seharusnya memperhatikan akronim API. Sebenarnya, dokumentasi API adalah hal pertama yang harus dipelajari pengembang jika mereka ingin memahami interaksi dengan beberapa layanan atau aplikasi di jaringan.

API

API - Antarmuka Pemrograman Aplikasi . Ini adalah deskripsi cara di mana klien dan server dapat berkomunikasi satu sama lain. Kami membuka dokumentasi API dan belajar dari sana cara mendapatkan data yang diperlukan dari server.

Kami selalu ingin interaksi ini sederhana dan dapat dimengerti. Ini menyederhanakan tugas untuk kedua pengembang (tidak perlu menemukan kembali roda saat merancang layanan baru) dan pengguna (layanan jauh lebih mudah dipelajari jika bekerja dengan prinsip yang sama seperti layanan yang sudah dikenal sebelumnya). Dan di sini perlu diingat istilah baru - REST.

ISTIRAHAT

REST -singkatan dari Representational State Transfer . Ini mungkin tidak terdengar sangat jelas, tetapi sederhananya, REST adalah gaya interaksi (pertukaran informasi) antara klien dan server.

Ini bukan seperangkat aturan dan persyaratan yang kaku. REST tidak memaksa penggunaan bahasa pemrograman tertentu, juga tidak mengikat tangan dengan pedoman yang ketat. REST disebut gaya arsitektur dan mendefinisikan 6 prinsip yang harus dipatuhi oleh arsitektur sistem.

Oleh karena itu, API yang dikembangkan dengan mempertimbangkan prinsip-prinsip REST disebut REST API , dan aplikasi itu sendiri disebut RESTful

Kami akan membuat aplikasi RESTful seperti itu, jadi ada baiknya mendiskusikan prinsip-prinsip yang akan mereka patuhi segera.

Prinsip RESTful

Model Server-Klien . Prinsip mendefinisikan pemisahan klien dan server, diferensiasi kebutuhan mereka. Klien tidak perlu khawatir tentang bagaimana data disimpan, yang utama adalah bahwa itu dikeluarkan berdasarkan permintaan. Pada gilirannya, server tidak peduli apa yang akan dilakukan klien dengan data ini, bagaimana memproses dan menampilkannya lebih lanjut. Ini memungkinkan mereka untuk berkembang secara independen satu sama lain, dan meningkatkan skalabilitas sistem.

Tanpa kewarganegaraan . Prinsip ini berarti bahwa server tidak boleh "memikirkan" respons berdasarkan pengalaman sebelumnya dengan klien ini. Setiap permintaan dibuat sedemikian rupa sehingga berisi semua informasi yang diperlukan untuk pemrosesannya, terlepas dari permintaan sebelumnya.

Caching . Untuk meminimalkan data yang dikirimkan, ada mekanisme caching. Misalnya, jika logo ditampilkan di beberapa halaman, maka tidak masuk akal untuk memintanya dari server setiap saat. Itu tidak sering berubah, itu akan cukup untuk mendapatkannya sekali dan menyimpannya di komputer klien, di cache. Tetapi jika kita perlu mendapatkan informasi tentang kecepatan mobil saat ini, maka cache tidak akan membantu dengan cara apa pun. Prinsip ini menentukan bahwa data yang dikirimkan oleh server harus ditetapkan sebagai cacheable atau tidak.

Antarmuka seragam . Prinsipnya mendefinisikan format tunggal interaksi client-server. Struktur semua permintaan harus sama. Data harus dikirim dalam bentuk yang sama, terlepas dari siapa yang memintanya.

Sistem Berlapis . Klien dan server tidak harus berkomunikasi secara langsung. Transmisi data dapat melalui beberapa node perantara. Dalam hal ini, sistem dirancang sedemikian rupa sehingga baik klien maupun server tidak tahu apakah mereka berinteraksi dengan aplikasi akhir atau simpul perantara. Ini memungkinkan Anda untuk menyeimbangkan beban di server, meningkatkan skalabilitas.

Kode sesuai permintaan (opsional) . Satu-satunya prinsip yang tidak wajib. Menurutnya, klien dapat memperluas fungsinya dengan mengunduh kode yang dapat dieksekusi dari server (misalnya, skrip). Dalam hal ini, kode harus dieksekusi hanya sesuai permintaan.