Nessuno nella comunità REST dice che REST è facile. HATEOAS è solo uno degli aspetti che aggiunge difficoltà a un'architettura REST.
Le persone non fanno HATEOAS per tutti i motivi che suggerisci: è difficile. Aggiunge complessità sia al lato server che al client (se si desidera effettivamente trarne vantaggio).
TUTTAVIA, oggi miliardi di persone sperimentano i vantaggi di REST. Sai qual è l'URL di "checkout" su Amazon? Io non. Tuttavia, posso effettuare il checkout ogni giorno. Quell'URL è cambiato? Non lo so, non mi interessa.
Lo sai che ci tiene? Chiunque abbia scritto uno schermo ha raschiato il client automatizzato di Amazon. Qualcuno che probabilmente ha analizzato meticolosamente il traffico web, letto pagine HTML, ecc. Per trovare quali collegamenti chiamare quando e con quali payload.
E non appena Amazon ha cambiato i propri processi interni e la struttura degli URL, quei client hardcoded hanno fallito, perché i collegamenti si sono interrotti.
Eppure, i navigatori occasionali del web erano in grado di fare acquisti tutto il giorno senza problemi.
Questo è REST in azione, è semplicemente aumentato dall'essere umano che è in grado di interpretare e intuire l'interfaccia basata su testo, riconoscere una piccola grafica con un carrello della spesa e scoprire cosa significa effettivamente.
La maggior parte delle persone che scrivono software non lo fa. Alla maggior parte delle persone che scrivono client automatizzati non interessa. La maggior parte delle persone trova più facile riparare i propri clienti quando si rompono che progettare l'applicazione in modo che non si rompa in primo luogo. La maggior parte delle persone semplicemente non ha abbastanza clienti dove conta.
Se stai scrivendo un'API interna per comunicare tra due sistemi con supporto tecnico esperto e IT su entrambi i lati del traffico, che sono in grado di comunicare le modifiche in modo rapido, affidabile e con una pianificazione delle modifiche, REST non ti compra nulla. Non ne hai bisogno, la tua app non è abbastanza grande e non è abbastanza longeva per essere importante.
I siti di grandi dimensioni con una vasta base di utenti presentano questo problema. Non possono semplicemente chiedere alle persone di cambiare il loro codice client per capriccio quando interagiscono con i loro sistemi. La pianificazione dello sviluppo dei server non è la stessa della pianificazione dello sviluppo del client. Le modifiche improvvise all'API sono semplicemente inaccettabili per tutte le persone coinvolte, poiché interrompono il traffico e le operazioni su entrambi i lati.
Quindi, un'operazione del genere molto probabilmente trarrebbe vantaggio da HATEOAS, poiché è più facile da aggiornare, più facile migrare per i client meno recenti, più facile essere retrocompatibili che non.
Un client che delega gran parte del suo flusso di lavoro al server e agisce sui risultati è molto più resistente alle modifiche del server rispetto a un client che non lo fa.
Ma la maggior parte delle persone non ha bisogno di questa flessibilità. Stanno scrivendo codice server per 2 o 3 dipartimenti, è tutto per uso interno. Se si rompe, lo riparano e l'hanno preso in considerazione nelle loro normali operazioni.
La flessibilità, sia da REST che da qualsiasi altra cosa, genera complessità. Se vuoi che sia semplice e veloce, allora non lo rendi flessibile, "fallo e basta" ed è fatto. Man mano che aggiungi astrazioni e dereferenziazione ai sistemi, le cose diventano più difficili, più elementi di base, più codice da testare.
Gran parte di REST fallisce il punto elenco "non ne avrai bisogno". Fino a quando, naturalmente, non lo fai.
Se ne hai bisogno, usalo e usalo così com'è. REST non spinge cose avanti e indietro su HTTP. Non lo è mai stato, è di livello molto più alto di quello.
Ma quando hai bisogno di REST e usi REST, allora HATEOAS è una necessità. Fa parte del pacchetto e una chiave per ciò che lo fa funzionare.