HATEOAS è un argomento un po 'controverso. Molte persone ritengono che sia un esempio di overengineering e non ne vedano alcun beneficio pratico. Credo che offra un approccio naturale e ragionevole per l'implementazione delle API Web, con i vantaggi di un maggiore disaccoppiamento tra server e client e un carico inferiore per gli sviluppatori client (vedere la mia risposta a" REST HATEOAS - Come fa il client a conoscere la semantica dei collegamenti? ").
Detto questo, a mia conoscenza ci sono ancora alcune convenzioni ben stabilite per le API Web. Farai i tuoi utenti e te stesso un favore adottando uno standard esistente come HAL , però:
-
Gli sviluppatori esperti capiranno subito la tua API senza dover apprendere le tue convenzioni esclusive.
-
Sarai in grado di utilizzare librerie come ROAR che generano rappresentazioni conformi agli standard più o meno automaticamente.
-
I client saranno in grado di utilizzare strumenti come HyperResource che utilizzano API conformi agli standard senza programmazione aggiuntiva.
Se decidi di definire i tuoi formati e le tue convenzioni (che è ancora la norma per i progettisti di API, per quanto ne so), non solo peserai il mondo con un'altra API completamente non standard che sarai aumentando il carico di proprio in termini di consegna di documentazione e codice di esempio ai clienti.