Aplikasi web, tenang atau tidak, umumnya bukan sekadar layanan data; itu memperlihatkan berbagai sumber daya dan menyediakan beberapa perilaku, dan karenanya ia memiliki keadaan; perbedaan dibuat antara status sumber daya (klien-independen, dikelola oleh aplikasi), dan status aplikasi , yang spesifik untuk klien. Aplikasi tanpa kewarganegaraan tidak menyimpan status aplikasi (khusus klien); alih-alih, itu memungkinkan klien bertanggung jawab untuk itu, dan menyediakan API yang memungkinkan untuk mentransfer status (aplikasi) bolak-balik (dengan demikian " S tate T ransfer" di RE ST). Dari perspektif klien, aplikasi web adalah mesin negara, berada di belakang API yang memungkinkan interaksi, tetapi bagian dari negara disediakan sebagai informasi kontekstual oleh klien, untuk melengkapi permintaan.
Sekarang, saat mempelajari REST, Anda mungkin menemukan sesuatu yang disebut The Richardson Maturity Model- ini menggambarkan "kematangan" API aplikasi web (berkembang selama bertahun-tahun), tetapi bermanfaat bagi kita sebagai semacam referensi yang menempatkan segala sesuatu dalam konteks. Dalam model ini, semua level kematangan, kecuali yang terakhir, pada dasarnya menyediakan API yang memfasilitasi RPC melalui HTTP. Dalam gaya desain API ini, HTTP digunakan sebagai mekanisme transportasi, tetapi komunikasi aktual terjadi melalui protokol khusus, sehingga sistem yang berinteraksi (klien dan aplikasi) bergantung pada apa yang disebut "informasi band keluar" untuk berkomunikasi (dalam hal ini konteks, ini hanya berarti bahwa sistem ini berkomunikasi menggunakan beberapa standar khusus daripada memanfaatkan hypertext / hypermedia dan, katakanlah, protokol HTTP yang ada). Jadi apa yang mendorong transfer negara dan transisi negara ("engine of application state") bukanlah hypermedia dalam kasus ini.
Tingkat kematangan akhir memperkenalkan batasan HATEOAS, dan hanya saat itulah API menjadi tenang. Klien memulai interaksi melalui URI awal; server merespon dengan representasi yang cocok berbasis hypermedia dari negara aplikasi (yang mungkin berbeda antara perangkat, atau klien, atau karena berbagai kondisi - sehingga " Re presentasi" di RE ST), yang meliputi tindakan self-describing yang memungkinkan klien memulai transisi status berikutnya (jadi hypermedia adalah apa yang secara langsung mendukung dan mendorong status aplikasi).
Dapatkah saya mengambil pernyataan bahwa "Status Aplikasi adalah khusus klien". Begitulah cara saya memahaminya. [...] Ini semua berkaitan dengan ketersediaan sumber daya sisi server, tidak ada (jelas yang bisa saya lihat) yang berkaitan dengan keadaan klien ...
Biarkan saya terlebih dahulu memastikan bahwa kita berada di halaman yang sama. Ini bukan keadaan klien (seperti pada, keadaan internal klien itu sendiri), melainkan keadaan aplikasi web yang khusus untuk klien tertentu.
Contoh yang Anda sebutkan tidak benar-benar menggambarkannya dengan baik, tetapi daftar tautan yang dikembalikan pada dasarnya dihasilkan secara dinamis di server dan mewakili transisi status yang saat ini tersedia, dan karenanya, menyandikan status aplikasi saat ini (untuk klien tertentu). Perhatikan bahwa Anda dapat memilih untuk mentransfer bit lain dari informasi terkait negara (di kedua arah) jika aplikasi Anda memerlukannya (sehingga Anda tidak terbatas pada metadata transisi negara), tetapi kendalanya adalah jangan pernah mengingat data khusus klien pada server, karena itu menyakiti salability. Perhatikan juga bahwa negara ini tidak harus lengkap (tidak harus sepenuhnya bermakna ketika Anda melihatnya secara terpisah), tetapi itu harus cukup bagi pihak penerima untuk membuat keputusan dan melakukan logika berdasarkan itu dan tidak ada yang lain (jadi,
HATEOAS memanfaatkan antarmuka seragam (standar umum dan format pertukaran data) untuk memisahkan klien dan server sehingga di sisi server mereka dapat mengaduk-aduk barang di belakang "kontrak" yang ditentukan oleh jenis hypermedia, tetapi juga karena komunikasi berdasarkan informasi band (protokol khusus) sering tidak memanfaatkan infrastruktur jaringan dengan cara yang ingin dilakukan REST. (Lihat diskusi di bawah ini.)
Dalam contoh Anda, klien tidak akan mendasarkan logikanya pada URI, tetapi pada metadata (atau anotasi), seperti atribut "rel". Misalnya, peramban tidak peduli tentang URI dalam tautan, ia hanya perlu mengetahui jenis tautannya (tautan yang dapat diklik, formulir yang dapat digunakan untuk membuat URI, referensi stylesheet, dll.)
ISTIRAHAT dalam Konteks
Sayangnya, REST telah menjadi kata kunci, dan semua orang berbicara tentang bagaimana menjadi RESTful, tetapi seluruh konteks REST hilang, dan Anda tidak dapat memahami gaya arsitektur REST tanpa memahami konteks ini (apa masalah sebenarnya REST mencoba menyelesaikan).
REST adalah generalisasi arsitektur di balik Web . Bagi kebanyakan dari kita, Web adalah sebuah platform. Tetapi bagi orang yang mengembangkan REST, WWW adalah sebuah aplikasi , yang memiliki serangkaian persyaratan tertentu, yang berjalan pada jaringan di seluruh dunia. Jadi REST dimaksudkan untuk sistem yang seperti Web dalam beberapa hal penting, yang perlu memuaskan seperangkat properti tertentu.
Ini adalah sistem jaringan skala besar yang berumur panjang (beberapa dekade). Ini adalah sistem yang menjangkau batas-batas organisasi (misalnya perusahaan yang berkolaborasi), atau batas-batas antara berbagai subtansi dalam organisasi besar (seperti divisi yang berbeda, dan bahkan tim). Meskipun ada kolaborasi, semua entitas yang terlibat sebagian besar beroperasi (bekerja, mengembangkan, dan menggunakan perangkat lunak) dengan persyaratan mereka sendiri, dengan kecepatan mereka sendiri, dengan masalah keamanan mereka sendiri, dan mereka semua menggunakan perangkat yang berbeda, sistem operasi, dll. perlu mengakses, dan berbagi referensi ke, sumber daya masing-masing (dokumen, layanan, data) masing-masing, sambil dapat berkembang secara mandiri dan bertahap, tanpa harus melakukan koordinasi yang luas (heck, sulit untuk membuat orang melakukan penyebaran yang terkoordinasi bahkan dalam organisasi yang sama).
Mereka yang menyediakan layanan harus dapat melakukan hal-hal seperti mengembangkan versi layanan, menambahkan node, atau mengacak data dengan efek minimal pada klien. Mereka perlu mengukur. Klien (yang mungkin merupakan layanan) perlu tetap bekerja terlepas dari semua aktivitas ini di sisi server. Sistem tersebut kemungkinan akan digunakan dengan cara yang tidak diantisipasi di masa depan. Sumber daya yang mereka akses dan tukar dapat dari berbagai jenis, dan direalisasikan (dikodekan, diketik, diwakili, terstruktur) secara internal (oleh penyedia layanan) dengan berbagai cara, tetapi meskipun demikian, untuk keseluruhan sistem / jaringan, cara yang konsisten untuk akses sumber daya dan struktur data dan respons diperlukan (antarmuka seragam).
REST memperhitungkan semua ini, dan sangat mempertimbangkan sifat-sifat jaringan. Ini dimaksudkan untuk memenuhi kebutuhan aplikasi yang, pada tingkat tinggi (dalam domain bisnis mereka sendiri), serupa dalam hal persyaratan dan kendala dengan apa yang diuraikan di atas (atau ingin menjadi).
Memang benar, tapi itu bukan obat mujarab. Ada biaya dan pertukaran. Itu memaksakan gaya komunikasi tertentu, dan ada hit kinerja. Anda selalu mentransfer data dengan cara kasar, seringkali data yang sama berulang kali, dalam format yang digeneralisasi (dan karenanya mungkin bukan yang paling efisien untuk layanan Anda), dengan sekelompok metadata, seringkali melintasi node jaringan menengah ( dengan demikian semua caching di Web - meminimalkan pengiriman data bolak-balik, menjaga klien dari layanan bila memungkinkan). Kinerja yang dirasakan pengguna penting, yang memengaruhi cara Anda menulis klien (inilah sebabnya browser mulai merender halaman sebelum semuanya diunduh atau siap). Tetapi Anda dengan senang hati membayar biaya itu untuk dapat membangun sistem dengan properti yang dijelaskan di atas.
Sebaliknya, jika Anda membangun sistem yang memiliki persyaratan / kendala berbeda, biayanya mungkin tidak sepadan.