Tak seorang pun di komunitas REST yang mengatakan REST itu mudah. HATEOAS hanyalah salah satu aspek yang menambah kesulitan pada arsitektur REST.
Orang tidak melakukan HATEOAS karena semua alasan yang Anda sarankan: itu sulit. Ini menambah kerumitan pada sisi server dan klien (jika Anda benar-benar ingin memanfaatkannya).
NAMUN, miliaran orang merasakan manfaat dari REST hari ini. Tahukah Anda apa itu URL "checkout" di Amazon? Bukan saya. Namun, saya dapat melakukan pembayaran setiap hari. Apakah URL itu berubah? Entahlah, aku tidak peduli.
Tahukah kamu apakah peduli? Siapa pun yang menulis layar melanggar klien otomatis Amazon. Seseorang yang mungkin dengan susah payah mengendus lalu lintas web, membaca halaman HTML, dll. Untuk menemukan tautan apa yang harus dipanggil kapan dan dengan muatan apa.
Dan segera setelah Amazon mengubah proses internal dan struktur URL mereka, klien yang diberi kode keras tersebut gagal - karena tautannya rusak.
Namun, para peselancar web biasa dapat berbelanja sepanjang hari tanpa hambatan.
Itu REST dalam tindakan, hanya ditambah dengan manusia yang mampu menafsirkan dan memahami antarmuka berbasis teks, mengenali grafik kecil dengan keranjang belanja, dan mencari tahu apa artinya sebenarnya.
Kebanyakan orang yang menulis perangkat lunak tidak melakukan itu. Kebanyakan orang yang menulis klien otomatis tidak peduli. Kebanyakan orang merasa lebih mudah untuk memperbaiki klien mereka ketika mereka rusak daripada merekayasa aplikasi agar tidak rusak di tempat pertama. Kebanyakan orang tidak memiliki cukup klien di tempat yang penting.
Jika Anda menulis API internal untuk berkomunikasi antara dua sistem dengan dukungan teknis ahli dan IT di kedua sisi lalu lintas, yang dapat mengomunikasikan perubahan dengan cepat, andal, dan dengan jadwal perubahan, maka REST tidak akan memberi Anda apa pun. Anda tidak membutuhkannya, aplikasi Anda tidak cukup besar, dan umurnya tidak cukup lama untuk menjadi masalah.
Situs besar dengan basis pengguna besar mengalami masalah ini. Mereka tidak bisa hanya meminta orang-orang untuk mengubah kode klien mereka saat berinteraksi dengan sistem mereka. Jadwal pengembangan server tidak sama dengan jadwal pengembangan klien. Perubahan mendadak pada API tidak dapat diterima oleh semua orang yang terlibat, karena mengganggu lalu lintas dan operasi di kedua sisi.
Jadi, operasi seperti itu kemungkinan besar akan mendapat manfaat dari HATEOAS, karena lebih mudah untuk versinya, lebih mudah bagi klien lama untuk bermigrasi, lebih mudah untuk kompatibel ke belakang daripada tidak.
Klien yang mendelegasikan sebagian besar alur kerjanya ke server, dan bertindak berdasarkan hasil jauh lebih kuat untuk perubahan server daripada klien yang tidak.
Tetapi kebanyakan orang tidak membutuhkan fleksibilitas itu. Mereka menulis kode server untuk 2 atau 3 departemen, semuanya penggunaan internal. Jika rusak, mereka memperbaikinya, dan mereka telah memperhitungkannya dalam operasi normal mereka.
Fleksibilitas, baik dari REST atau apa pun, menghasilkan kompleksitas. Jika Anda menginginkannya sederhana, dan cepat, maka Anda tidak membuatnya fleksibel, Anda "lakukan saja", dan selesai. Saat Anda menambahkan abstraksi dan dereferensi ke sistem, maka hal-hal menjadi lebih sulit, lebih banyak pelat boiler, lebih banyak kode untuk diuji.
Banyak dari REST gagal dalam poin peluru "Anda tidak akan membutuhkannya". Sampai, tentu saja, Anda melakukannya.
Jika Anda membutuhkannya, gunakanlah, dan gunakan seperti yang sudah ditata. REST tidak mendorong hal-hal bolak-balik melalui HTTP. Tidak pernah, ini jauh lebih tinggi dari itu.
Tetapi ketika Anda benar-benar membutuhkan REST, dan Anda menggunakan REST, maka HATEOAS adalah sebuah kebutuhan. Itu adalah bagian dari paket, dan kunci untuk membuatnya bekerja sama sekali.