HATEOAS é opcional em APIs REST?
Não!
Tem certeza? Há quem defenda que é. Aliás, tem que defenda que HATEOAS é uma má prática. Você discorda?
Sim!
Outra resposta direta! Mas, de onde vem toda essa certeza?
Simples. Da dissertação de doutorado do Roy Fielding, onde ele apresentou REST, criação dele, para o mundo. Também do posicionamento do próprio Fielding, preservado, depois da publicação desta dissertação.
Mas, o autor não pode estar errado?
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.
Mas, e o tal modelo de maturidade de Richardson?
Segundo Roy Fielding, apenas aplicações no nível 3 de maturidade, que inclui HATEOAS são REST.
Mas, então é errado criar APIs REST sem HATEOAS?
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).
Mas, não é errado criar APIs que não sejam REST?
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.
O vídeo que segue é uma discussão aprofundada sobre REST, parte da mentoria que ministro em arquitetura de software.
Esses alguma lib em .net que facilite a implementação de HATEAOS?