Bom, ele escreveu a dissertação, que foi revista e aprovada como uma proposta inédita por uma junta extremamente conceituada. Logo, dificilmente o autor estaria incorreto descrevendo algo que criou e indicou explicitamente.
Mas, será que não é mais um daqueles teóricos burocratas da academia?
Não! Roy Fielding trabalhou por anos na definição da WWW. Aliás, ele começou a utilizar REST como referência para esse serviço em 1994. O verbo PATCH, por exemplo, é criação dele.
Não, necessariamente! O que é errado é afirmar que uma API sem HATEOAS é REST. Podemos dizer que é uma HTTP Resource API, talvez. Ou, simplesmente, reconhecer que a API é RPC (aliás, na maioria dos casos, é o que temos).
Não! Cada time sabe, ou deveria saber, as demandas de sua arquitetura. Uma API que atende um único frontend Web ou aplicativo não precisa do nível de abstração e possibilidade de baixo acoplamento proporcionado por REST.
O que quer dizer com “baixo acoplamento” nesse contexto?
Veja, se sua aplicação cliente precisa assumir padrões de como o servidor funciona – como os links são estruturados e os verbos comuns – então, tem behaviour coupling elevado. Isso não é problema, se for para times pequenos. Entretanto, se um mesmo backend deve suportar um número desconhecido de clientes, então behaviour coupling compromete evolvability.
Mas, o que dizer do overhead de transferência de dados causado por HATEOAS?
Um mal necessário, mitigado com o uso intensivo de caching no lado do cliente. Aliás, outra imposição de REST.
HATEOAS, então não é uma má prática?
Nem boa, nem má! Eventualmente, APIs REST não são a escolha certa.
Mas, da forma como você afirma, pouca gente cria APIs REST?
Exatamente! Mas, infelizmente, temos o triste hábito de dar nomes certos para coisas erradas. Há quem chame organização de trabalho em entregáveis de duas semanas de SCRUM, quadros com post-its na parede (ou no Trello) de Kanban, monolíticos distribuídos de microsserviços. Com REST não haveria de ser diferente!
Mas, afinal, não é possível ter opiniões diferentes?
Infelizmente, não há margens, nesse tema, para opiniões. REST, diferente de muitos outros estilos arquiteturais é fundamentado em trabalho acadêmico reconhecido, de um autor excepcionalmente conceituado e cuidadoso com sua criação.
Somos livres para implementar HATEOAS ou não. Mas, quando optamos por não o fazer, estamos nos afastando de REST e… está tudo bem! Afinal, somos livres para fazer e sustentar escolhas arquiteturais que atendam os objetivos do negócio, respeitando restrições e atributos de qualidade.
Esses alguma lib em .net que facilite a implementação de HATEAOS?