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.
0
Considerações?x

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).
0
Por favor, deixe seu feedback aquix

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.
0
Considerações?x

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.
0
Concorda?x

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!
0
Considerações?x

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.
0
Considerações?x

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.
0
Considerações?x

O vídeo que segue é uma discussão aprofundada sobre REST, parte da mentoria que ministro em arquitetura de software.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este vídeo a seguir:

Subscribe
Notify of
1 Comentário
Oldest
Newest Most Voted
Feedbacks interativos
Ver todos os comentários
Renan Aragão
1 mês atrás

Esses alguma lib em .net que facilite a implementação de HATEAOS?

Este site é protegido por reCAPTCHA e Google – Política de Privacidade e Termos de serviço.

ElemarJúnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Insights e provocações sobre tecnologia e negócios. Conteúdo fora do “lugar comum” para quem gosta de pensar “fora da caixa”.

ElemarJúnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

19/03/2021

Bulkheads: solução arquitetural para “isolar” instabilidades

19/03
2021
04/03/2021

Por onde começar a explicitar arquiteturas de sistemas?

04/03
2021
18/02/2021

Usando “Back-of-the-envelope calculations” para projetar sistemas escaláveis

18/02
2021

TECH

&

BIZ

-   Insights e provocações sobre tecnologia e negócios   -   

1
0
Quero saber a sua opinião, deixe seu comentáriox
()
x