HATEOAS - MÁS PRÁTICAS - REST
Вставка
- Опубліковано 20 лип 2021
- Já ouviu falar do HATEOAS?
Será que é importante para sua API REST?
Assista e compartilhe sua opinião conosco!
Referências para esse video.
Two bit history:
twobithistory.org/2020/06/28/...
OAuth 2.0 Simplified
www.amazon.com/OAuth-2-0-Simp...
API RESTful - Boas Praticas
www.brunobrito.net.br/api-res...
-------------------------------------------------------------------------------------------
Realize seu cadastro e comece a estudar agora mesmo:
desenvolvedor.io/
INSTAGRAM:
/ desenvolvedor.io
FACEBOOK:
/ desenvolvedor.io
LINKEDIN:
/ desenvolvedor-io
-------------------------------------------------------------------------------------------
Apresentador:
BRUNO BRITO
/ bhdebrito
#REST #RESTFUL #HATEOAS #API #HTTP
Cara que vídeo sensacional, enfim alguém que fala mesmo e não tem medo de falar mal de coisas que viram modinhas. Parabéns pelo vídeo Bruno, foi direto ao ponto e com uma excelente base técnica. Já encaminhei para uns amigos aqui fãboys de HATEOAS rsrsrs
Conheci o recurso hoje e já vem a decepção! kkkk... Mais um seguidor com este vídeo, pra mim fez todo sentido! Um abraço!
É mais uma daquelas coisas que muitas aplicações usam porque "alguém falou que é bom", concordo muito com sua visão.
Nossa. Gostei muito do vídeo. Parabéns! Aprendi muito.
Obrigado pelo contéudo mestre Bruno!
Perfect
Valeu a aula Brunão!
Muito boa a sinceridade no vídeo
Rapaz, gostei muito de ter visto esse vídeo. Nunca achei que esse tal de HATEOAS serviria para alguma coisa... rsrs
Oi!! Deixar aqui uma sugestão de tema pra vcs falarem: Pull Requests, presente na maioria das equipes, mas ninguém fala sobre. Como deveriam ser, o que analisar, etc. Tenho muita dificuldade em analisar os PRs das outras pessoas.
Não usamos PR pq a equipe não está madura e é pior para resolver conflitos.
Tbm quero opiniões sobre o tema.
@@thiagocola E como vocês fazem então??????? saem fazendo merge direto na develop ou Release? Vocês não utilizam git-flow? PQP... por isso que a gente não é respeitado e as empresas nos oferecem salários de fome! Tá cada vez pior trabalhar nessa área! meu Deus!
@ Você é sempre assim? Faz acusações sem conhecimento de causa? Pessoas assim não são bem vindas na equipe.
@ Cada dev cria sua branch da master e cada uma sobe individualmente para cada ambiente. Cada branch homologada pode subir sem depender de outra (98% dos casos não é cross) e a cada subida pra produção os devs fazem a volta da master em suas branches. E uma pessoa é eleita integrador para fazer os merges (até que a equipe fique madura).
Independentemente de concordar ou não (eu concordo), gostei muito da abordagem de embasar a opinião como fatos sólidos e exemplos e acima de tudo deixar claro que é uma opinião pessoal (sem querer ser o dono da verdade)
Legal, aqui eu talvez tenha visto a outra extremidade do uso do HATEOAS.
Eu nunca usei o HATEOAS, então não tenho muito o que opinar de forma concreta, mas abaixo eu deixo o meu pensamento.
O que eu acho interessante no HATEOAS é permitir diminuir regra de negócio no frontend, pois nos links retornados do backend já irá dizer se determinada operação está disponível ou não para aquele recurso, porém ao mesmo tempo eu vejo uma certa complexidade em administrar isso no backend, mas não sei se deveria ser complexo, pois a lógica para recusar/permitir as operações já estão implementadas no backend para quando forem solicitadas.
É meio natural, quando algo não é útil de fato no mundo real cai em desuso. É o caso do HATEOAS com suas raras exceções.
Oi, muito interessante o video, eu gostaria de saber se a sua opinião mudou com o HTMX que resgata o hateoas.
q isso jovem
Compactuo contigo, implementar hateoas não resolve nenhum problema e ainda cria mais 2 novos, sobrecarrega o consumo de dados e injeta complexidade desnecessária no código que vai cobrar seu preço na hora de implementar 1 endpoint novo, em vez de fazer em 2h vc vai levar 2 dias.
Realmente, a internet está repleta de HATERS... ah não, péra!
Acho que você quis dizer que a WEB é HATEOAS (e não a INTERNET), certo? A rede de documentos conectados por Hipertexto, e não a rede de computadores.
Até onde entendo a principal vantagem do HATEOAS é a capacidade de evoluir a API ao longo do tempo. Se o client utilizar os links das respostas ao invés de ter eles hardcoded, é possível mudar as URLs o quanto precisar que não vai quebrar o client
Interessante
Vlw.. um vídeo feito em KISS.. kkkkk
Eu gostei muito do vídeo, inclusive da parte onde fala sobre pesar o que é necessário contra o que não é. Avançar para o terceiro nível não é obrigatório e muito menos necessário na maior parte das vezes. A maior parte dos grandes sistemas disponíveis no mercado fica exatamente no segundo nível e não sai daí. O argumento sobre os bytes adicionais não é descartável, mas o tamanho da resposta continua sendo gerenciável nesse caso. Para aproveitar de verdade o terceiro nível, o máximo que posso extrair dai é a isenção da gestão de uma parte do estado na própria aplicação. Exemplo: Se a resposta da API possui as ações permitidas, a aplicação não precisa mais testar ou calcular nada para renderizar um botão ou um input específico.
Parabéns pelo vídeo!
Mas WPF é bom, tem os seus problemas, mas não tem nada melhor para fazer programas desktop windows (por enquanto)
Nao acho que se encaixe em todas api, ou isso fazer parte do restful. Mas dizer que isso eh uma ma pratica ou nao presta para nada. Isso parece ser extremismo e ignoracia.
Alguns caso que recomendo usar.
Nem toda api tem font end, e assim com o clean code diz que o documentação eh o proprio codigo, navegar pela requisição eh melhor que voce ficar lendo o swagger da api (em apis que precisem ser feito).
Outra coisa a validacao de acesso o ideal eh ela ficar no back end, o back passando o que aquele usuario tem acesso, o front saber o que podera mostra e o que nao podera para aquele usuario, daquela entidade.
de novo, nao acho que tudo precise de rest ful. Mas nunca seja extremista.
eu concordo com seu ponto, mas vc foi meio agressivo na argumentação kkkkk
Cara eu estou estudando ainda e cheguei nesse negócio de hateoas, sinceramente não vi fundamento prático nisso. Além de adicionar complexidade ao projeto. 😂