8.1 Pendekatan API jarak jauh
Semua programmer melakukan kesalahan yang sama saat membangun arsitektur client-server. Mereka mulai memperlakukan permintaan ke server sebagai pemanggilan metode .
Anda ingin memulai proses pembuatan laporan di server, mengapa tidak mengirimkan permintaan seperti:
http://server.com/startDocumentGeneration?params
Dan bagaimana cara mengunduh laporan setelah selesai? Untuk melakukan ini, kami akan menulis metode lain:
http://server.com/getDocument
Server HttpSession
menyimpan informasi tentang dokumen kami, dan segera setelah dokumen dibuat, server akan mengembalikannya.
Pendekatan yang bagus. Atau tidak?
Pendekatannya sangat mengerikan. Masalahnya adalah server harus mengingat nomor dokumen. Dengan kata lain, untuk memproses pemanggilan metode baru dengan benar, server harus mengingat hasil pemanggilan metode sebelumnya.
Di web, ini adalah masalah besar. Internet mungkin hilang, browser mungkin tertutup. Halaman dapat dimuat ulang atau secara tidak sengaja mengklik tautan, dan sebagainya. Dan server akan terus menyimpan megabyte data dari permintaan pengguna sebelumnya ...
Untuk pekerjaan yang nyaman dengan server, Anda tidak dapat berharap bahwa Anda akan selalu memiliki data permintaan sebelumnya ke server.
Lalu bagaimana cara memanggil metode server? Jawaban yang benar akan sangat buruk: tidak mungkin!
8.2 pendekatan REST
Pemrogram kembali ke dasar dan ingat bahwa permintaan awalnya berisi jalur ke file di server:
http://server.com/path?params
Dan kami memutuskan untuk menggunakan pendekatan ini secara maksimal.
Sekarang server dianggap sebagai tempat penyimpanan data yang terlihat dari luar dalam bentuk pohon .
Jika Anda ingin mendapatkan daftar semua pengguna, panggil kueri:
http://server.com/users
Jika Anda ingin mendapatkan data tentang pengguna 113, jalankan kueri:
http://server.com/users/113
Dan seterusnya, semuanya dalam nada yang sama.
Sekali lagi, server dilihat sebagai gudang data yang terlihat di luar dalam bentuk pohon.
Data dapat diterima - permintaan GET , dimodifikasi - permintaan POST dan dihapus - permintaan DELETE .
8.3 Tidak ada status
Protokol interaksi REST antara klien dan server memerlukan kondisi berikut: selama periode antara permintaan dari klien, tidak ada informasi tentang status klien yang disimpan di server.
Semua permintaan dari klien harus dibuat sedemikian rupa sehingga server menerima semua informasi yang dibutuhkan untuk memenuhi permintaan setiap waktu . Status sesi disimpan di sisi klien.
Selama pemrosesan permintaan klien, klien dianggap dalam keadaan transisi. Setiap status aplikasi individual diwakili oleh tautan yang dapat dipanggil saat klien masuk lagi.
8.4 Keseragaman antarmuka
Semua jalur yang digunakan untuk mengambil objek dari server dibakukan. Ini sangat nyaman, terutama jika Anda mendapatkan data dari server REST lainnya.
Semua antarmuka objek harus mematuhi tiga syarat:
Identifikasi sumber daya
Semua sumber daya diidentifikasi dalam permintaan menggunakan URI. Sumber daya di dalam server terpisah dari tampilan yang dikembalikan ke klien. Misalnya, server dapat mengirim data dari database sebagai HTML, XML, atau JSON, yang keduanya bukan tipe penyimpanan di dalam server.
Memanipulasi Sumber Daya Melalui Tampilan
Jika klien menyimpan representasi sumber daya, termasuk metadata, maka klien memiliki informasi yang cukup untuk mengubah atau menghapus sumber daya di server.
Pesan "menggambarkan diri sendiri".
Setiap pesan berisi informasi yang cukup untuk memahami cara memprosesnya. Misalnya, jika Anda memerlukan informasi tentang pengguna, maka server akan mengembalikan objek JSON kepada Anda, di mana akan ada bidang nama, alamat.
Seharusnya tidak ada situasi di mana klien perlu mengetahui bahwa angka pertama dalam jawaban adalah usia, dan yang kedua adalah tanggal lahir.
8.5 Penyimpanan cache
Pendekatan REST mengasumsikan bahwa permintaan data dilakukan melalui protokol HTTP. Oleh karena itu, objek diperoleh dengan memanggil permintaan GET. Ini berarti bahwa mereka, seperti semua sumber daya yang diterima melalui permintaan GET, tunduk pada semua aturan untuk menyimpan sumber daya HTTP ke cache.
Artinya, data yang diterima melalui REST API di-cache dengan cara yang sama seperti sumber daya statis apa pun di server web. Kecantikan :)
GO TO FULL VERSION