Apakah REST dan HATEOAS arsitektur yang baik untuk layanan web?

Jika saya mengerti benar, REST diresmikan oleh Roy Fielding sebagai model deskriptif dari arsitektur web. AFAIK Fielding tidak mengklaim REST itu bagus, dia hanya menggambarkan arsitektur web secara de-facto. Web pada saat ini telah membuktikan sistem hiperteks terdistribusi yang sangat sukses, sehingga jenis ini mengesahkan REST sebagai arsitektur yang sukses untuk domain hypermedia yang didistribusikan, terutama dinavigasi dan dikonsumsi oleh manusia.

Layanan web REST dibuat dengan menerapkan arsitektur REST ke API. Tetapi apakah sebenarnya ada alasan untuk berpikir REST adalah arsitektur yang diinginkan untuk domain ini? Lebih khusus, apakah ada bukti yang mengatakan HATEOAS adalah prinsip desain yang bermanfaat untuk komunikasi mesin-ke-mesin?

Kekhawatiran saya adalah bahwa HATEOAS masuk akal untuk hypermedia karena ada beberapa jenis konten yang terkenal (HTML, gambar, video dll) dan klien tahu bagaimana mengkonsumsinya. Tetapi untuk API jenis kontennya sangat spesifik dan hanya dapat dikonsumsi dengan cara yang bermakna oleh klien jika klien diprogram khusus untuk mengkonsumsinya. Mengembalikan URL ke klien tidak dengan sendirinya membuat klien dapat mengkonsumsi sumber daya yang ditunjukkan.

AFAIK Fielding tidak mengklaim REST itu bagus, dia hanya menggambarkan arsitektur web secara de-facto.

Saya pikir itu sedikit menjualnya. REST adalah, setelah semua, penghitungan dari gaya arsitektur yang Fielding menggunakan sebagai kepala arsitek dari HTTP / 1.1 spec .

Tetapi apakah sebenarnya ada alasan untuk berpikir REST adalah arsitektur yang diinginkan untuk domain ini? Apakah ada bukti yang mengatakan HATEOAS adalah prinsip desain yang bermanfaat untuk komunikasi mesin-ke-mesin?

"Tergantung". HATEOAS adalah bagian dari batasan antarmuka seragam REST.

Dengan menerapkan prinsip rekayasa perangkat lunak generalitas ke antarmuka komponen, arsitektur sistem keseluruhan disederhanakan dan visibilitas interaksi ditingkatkan. Implementasi dipisahkan dari layanan yang mereka berikan, yang mendorong evolvabilitas independen. Namun, trade-off adalah antarmuka yang seragam menurunkan efisiensi, karena informasi ditransfer dalam bentuk standar daripada yang khusus untuk kebutuhan aplikasi. Antarmuka REST dirancang agar efisien untuk transfer data hypermedia berbutir besar, mengoptimalkan untuk kasus umum Web, tetapi menghasilkan antarmuka yang tidak optimal untuk bentuk lain dari interaksi arsitektur.

Jadi mari kita berpikir sejenak tentang apa artinya ini. Ketika saya mengalami masalah dengan router nirkabel saya, saya dapat berkomunikasi dengannya menggunakan browser yang sama yang saya gunakan untuk mengirimkan jawaban ke stackexchange. Secara khusus, tidak masalah apa browser yang saya gunakan, atau apakah browser saya beberapa pembaruan di belakang (atau di depan) dari apa yang diharapkan router. Tidak masalah bahwa organisasi teknik yang menulis peramban sepenuhnya independen dari organisasi yang menciptakan antarmuka router.

Itu hanya bekerja .

Tentu saja ini tidak universal. Fielding, pada 2008 , menulis:

Itu tidak berarti bahwa saya pikir semua orang harus merancang sistem mereka sendiri sesuai dengan gaya arsitektur REST. REST ditujukan untuk aplikasi berbasis jaringan yang berumur panjang yang menjangkau banyak organisasi. Jika Anda tidak melihat perlunya kendala, maka jangan menggunakannya.

Kendala yang membentuk gaya arsitektur REST dipilih untuk properti yang diinduksi; jika properti tersebut tidak bernilai untuk use case Anda, maka Anda harus benar-benar mempertimbangkan untuk menjatuhkan batasan yang sesuai.

Di mana mesin ke mesin menjadi sulit, adalah bahwa Anda telah kehilangan kemampuan manusia untuk kabur cocok dengan semantik yang disediakan oleh representasi. Klien bisa bertahan dengan hanya mengetahui jenis media, tetapi kami biasanya memiliki manusia yang melihat isyarat semantik untuk mendapatkan makna.

schema.org adalah salah satu bagian dari upaya untuk menciptakan kosakata yang dapat dibaca mesin; agen mesin menggunakan klien untuk menemukan petunjuk semantik, dan menerapkan pemahamannya sendiri tentang makna untuk memilih tindakan yang benar untuk diambil.

Tapi ini berhasil; Anda perlu berinvestasi dalam mengembangkan representasi ramah mesin dari sumber daya Anda, dan memastikan bahwa representasi tersebut tetap maju dan mundur kompatibel, sehingga klien dapat dikembangkan secara mandiri.

Ketika satu organisasi mengendalikan klien dan server, manfaat independensi ini jauh lebih kecil, dalam hal ini kendala mungkin bukan pilihan arsitektur yang tepat.

Tidak, 'REST lengkap' tidak terlalu bagus.

Sebagaimana dibuktikan oleh kurangnya orang yang menerapkan HATEOS di API mereka dan argumen tak berujung yang menggunakan kata kerja HTTP untuk panggilan tertentu.

Tetapi Anda harus menyadari mengapa REST begitu populer. Sebelum diadopsi, ada berbagai protokol rumit yang gila seperti ebXML dan SOAP yang melibatkan ucapan terima kasih, batas waktu, Id percakapan dan status.

Menjalankan dan menjalankannya lalu menjelaskannya kepada konsumen api adalah tugas yang sulit. "Mengapa saya tidak melakukan GET dengan id yang saya inginkan dalam string kueri dan Anda mengirimi saya datanya?" adalah pertanyaan yang jelas dan umum.

Kemudian masalah kedua adalah XML, javascript tidak memahaminya, skema yang menyebalkan dan Anda akan berakhir dengan file txt besar yang sebagian besar terdiri dari <MyLongObjectName>. Jadi orang-orang mulai menggunakan JSON sebagai gantinya.

Sekarang REST memiliki sedikit sekte di sekitarnya, tetapi karena aturannya sangat samar, itu tidak mencegah Anda mengetuk API yang dapat digunakan yang cukup sederhana sehingga konsumen akan 'mendapatkannya' dan menggunakannya tanpa 6 bulan naik ke pesawat. proses.

Perlu dicatat bahwa Roy bukan penemu asli dari sebagian besar prinsip REST, ia menyatukan banyak prinsip yang diketahui bekerja di sistem sebelumnya untuk menyelesaikan berbagai masalah spesifik. REST hanyalah kesimpulan alami dari penerapan prinsip-prinsip ini dalam satu arsitektur.

Bahkan sebelum Roy Fielding menulis disertasinya tentang REST , HTTP sudah dirancang berdasarkan prinsip-prinsip yang kemudian dikenal sebagai REST. Di akhir disertasinya , ia menulis:

Pada awal upaya kami dalam Gugus Tugas Teknik Internet untuk menentukan Protokol Transfer Hiperteks yang ada (HTTP / 1.0) [19] dan merancang ekstensi untuk standar baru HTTP / 1.1 [42] dan Uniform Resource Identifiers (URI) [21] ], Saya menyadari perlunya model bagaimana World Wide Web seharusnya bekerja. Model interaksi yang ideal ini dalam aplikasi Web secara keseluruhan, yang disebut sebagai gaya arsitektur Representational State Transfer (REST), menjadi fondasi untuk arsitektur Web modern, memberikan prinsip-prinsip penuntun yang dengannya kelemahan dalam arsitektur yang sudah ada dapat diidentifikasi dan ekstensi divalidasi sebelum penempatan .

REST dan HATEOS sangat cocok untuk masalah yang dirancang untuk:

REST adalah seperangkat kendala arsitektur terkoordinasi yang berupaya meminimalkan latensi dan komunikasi jaringan sekaligus memaksimalkan kemandirian dan skalabilitas implementasi komponen . Ini dicapai dengan menempatkan batasan pada semantik konektor di mana gaya lain telah berfokus pada semantik komponen. REST memungkinkan penyimpanan dan penggunaan kembali interaksi, penggantian komponen yang dinamis, dan pemrosesan tindakan oleh perantara , sehingga memenuhi kebutuhan sistem hypermedia skala Internet yang didistribusikan.

Namun, perlu dicatat bahwa Web dan REST tidak selalu cocok untuk setiap masalah:

Demikian juga, ekstensi yang diusulkan dapat dibandingkan dengan REST untuk melihat apakah ekstensi tersebut sesuai dengan arsitektur; jika tidak, lebih efisien untuk mengalihkan fungsi itu ke sistem yang berjalan secara paralel dengan gaya arsitektur yang lebih berlaku.

Jadi, jika pertanyaan Anda adalah "Apakah REST dan HATEOAS arsitektur yang bagus untuk layanan web?" kemudian, jawabannya sederhana "ya, itu adalah arsitektur yang bagus untuk layanan web". Masalahnya benar-benar adalah apakah semua masalah yang orang coba selesaikan dengan retrofit ke dalam batasan web, sebenarnya seharusnya merupakan layanan web.

Ada banyak API yang benar-benar tidak cocok dengan REST. API yang tidak membutuhkan skalabilitas yang dirancang untuk diselesaikan oleh REST, tidak dikonsumsi oleh banyak organisasi yang dapat berkembang secara independen, dan tidak perlu berumur panjang; untuk masalah ini, kendala REST hanyalah jaket pelindung.

Tetapi apakah sebenarnya ada alasan untuk berpikir REST adalah arsitektur yang diinginkan untuk domain ini? Lebih khusus, apakah ada bukti yang mengatakan HATEOAS adalah prinsip desain yang bermanfaat untuk komunikasi mesin-ke-mesin?

Buktinya adalah keberhasilan Web dalam memecahkan masalah banyak orang. REST adalah arsitektur hybrid, yang menggabungkan desain dari banyak gaya arsitektur sebelumnya. Banyak domain bermasalah tidak memiliki semua persyaratan Web, dan tidak perlu mematuhi semua kendala REST untuk berkinerja baik. Inilah sebabnya mengapa ada banyak arsitektur yang berhasil yang berfungsi baik dengan hanya menerapkan beberapa bagian REST tetapi tidak yang lain. HATEOAS dan Uniform Interface, misalnya, adalah prinsip yang sering dilewati oleh API yang tidak perlu melintasi batas organisasi dan sistem yang memiliki periode penghentian yang relatif singkat.

Dalam presentasi Fielding tentang Adobe Experience Manager:

REST BUKAN arsitektur!

Istirahat adalah gaya arsitektur, yang merupakan abstraksi dari berbagai arsitektur yang ada di internet.

REST adalah akumulasi kendala desain untuk menginduksi properti arsitektur

REST adalah kata kunci, dan semua orang ingin memiliki RESTful API. Pada kenyataannya, ketika orang dihadapkan dengan kendala REST, mereka menjatuhkan beberapa kendala ini karena tidak perlu atau tidak ada manfaat yang dapat diperoleh bagi mereka untuk menerapkan semua kendala.

Seperti yang Anda sebutkan, HATEOAS berguna ketika klien adalah browser web. Ketika klien adalah aplikasi seluler, mungkin tidak terlalu banyak. Ini akan menjadi praktik yang baik, tetapi ada juga biaya yang terkait dengan mendesain aplikasi seperti itu, sedemikian rupa sehingga, sebagai contoh, tim aplikasi seluler dan tim back end hanya setuju untuk menghilangkan batasan itu. Dan itu masuk akal karena kedua tim tidak terlalu longgar karena mereka bekerja untuk perusahaan yang sama.

SISA di AEM

jika yang Anda inginkan adalah membuat layanan yang dikonsumsi oleh server lain, maka xmlrpc adalah pilihan yang tepat. Jika yang Anda inginkan adalah layanan yang dapat dikonsumsi oleh klien tipis atau perangkat berdaya rendah .. atau klien tidak dikenal melalui internet terbuka, mungkin sebaiknya Anda menggunakan json. Tapi ingat, json adalah notasi yang lebih rendah untuk menentukan data umum, jika dibandingkan dengan xml.