Opa Francis, pois é! Isto é justamente pelo que falei no vídeo. REST foi vítima do próprio sucesso, acabou sendo banalizado, então acabou-se se espalhando que REST é http + json, então se uns fazem assim, todo mundo faz e etc. Roy já falava desta frustação desde 2008. Obrigado pelo feedback!
E daí, entrega aos invasores todos os recursos do sistema. Se não for uma API pública, pode até fazer isso, mas com algum sistema de autenticação se tratar de dados sensíveis.
Oi Edilvaldo, tudo bem? Obrigado por dar seu ponto de vista. Mesmo sendo uma API sensível, temos meios de garantir mais segurança se necessário, o endpoint raiz pode ser validado para somente clientes permitidos poderem acessar, temos - autenticação - cors - etc Não é obrigatório uma API estar sempre com todos os recursos expostos, mas para ser considerada uma API Restful precisa trabalhar no nível 3 de maturidade.
Eu nem tento fazer API Restfull, acho o conceito péssimo na prática, pra mim o conhecimento é util pra entrevistas de emprego e no máximo pra fazer crud... e estou falando de nem respeitar o nível 1... é um pesadelo pra integridade e segurança fazer o front chamar uma dúzia verbos em uma dúzia de recursos... o front não precisa saber que entidades foram alteradas, o que foi criado, o que foi alterado, etc... Exemplo prático... temos uma gestão de candidatos no nosso sistema... quando alguém se candidata o sistema: 1) Cria um registro de candidato 2) Um candidato pode ter entrado por uma URL com link de indicação, se for o caso notifica o mentor ligado aquela URL de indicação 3) Lança um registro informando que o candidato entrou na fase de Análise Inicial pelo Mentor Tudo isso é feito em uma única chamada... o front não precisa saber que isso acontece, nem deve saber, nunca que cada um seria um "resource" chamado pelo meu front.
Apesar dessa abordagem ser a correta ao ser referir a rest em aplicações grandes o json ficaria muito grande e na Cloud os dados tem custo para trafegar e foi um dos motivos da criação do GraphQL que é um Post com consulta, não vejo vantagem em expor os link pode dar dicas a atacantes maliciosos
Oi Jorge, tudo bem? Os dados tendem a ficar maiores sim, mas aí entra um dos pilares do rest que é poder fazer cache com qualquer componente envolvido na arquitetura como browser, proxy cache e outros. O uso de protocolo http 1.1 e dos cache-control, etag, last-modified servirão para otimizar a comunicação, diminuição a latência e os dados trafegados. Em várias situações, a resposta já estará no browser ou nem vai bater na API, baterá num proxy cache e ainda é possível usar o header etag fazendo com que se a resposta não mudou, só retorna status 304 modified, então o cliente reusa o cache local que ele tinha. O cache é um dos 5 pilares fundamentados pelo Roy Fielding na dissertação dele. Na verdade o uso de cache deveria ser muito mais comum com http, mas cache é só visto do lado da aplicação, como fazer cache com redis, no banco de dados e etc. São trade-offs, aumentamos os dados por uma melhor navegabilidade na API que a torna auto-documentada e muitas vezes o grande volume de dados retorno pode ser um mal design dos recursos
Obrigado, professor. Essa foi a melhor aula de API Rest que eu já vi na minha vida!! 🎉💪🏼
Que interessante. Nunca nem vi alguma api que implementasse isso.
Já trabalhei em projeto Restful, confesso que era complicado entender naquela época. Queria ter encontrado essa explicaçao antes. =)
Opa Francis, pois é! Isto é justamente pelo que falei no vídeo. REST foi vítima do próprio sucesso, acabou sendo banalizado, então acabou-se se espalhando que REST é http + json, então se uns fazem assim, todo mundo faz e etc. Roy já falava desta frustação desde 2008.
Obrigado pelo feedback!
Brabo kkkk top, agora minha duvida este em como implementar isso
Obrigado pelo feedback Angelo!
Usar html. Json não foi feito pra restful. O que a gente faz nos serviços backend é API HTTP, mas nunca restful
Esse vídeo apareceu pra mim, ' do nada ' , ai Meu Deus, será que eu AINDA, ALGUM DIA, serei um Dev?? 😔
Vair dormir
E daí, entrega aos invasores todos os recursos do sistema. Se não for uma API pública, pode até fazer isso, mas com algum sistema de autenticação se tratar de dados sensíveis.
Oi Edilvaldo, tudo bem?
Obrigado por dar seu ponto de vista.
Mesmo sendo uma API sensível, temos meios de garantir mais segurança se necessário, o endpoint raiz pode ser validado para somente clientes permitidos poderem acessar, temos
- autenticação
- cors
- etc
Não é obrigatório uma API estar sempre com todos os recursos expostos, mas para ser considerada uma API Restful precisa trabalhar no nível 3 de maturidade.
Eu nem tento fazer API Restfull, acho o conceito péssimo na prática, pra mim o conhecimento é util pra entrevistas de emprego e no máximo pra fazer crud... e estou falando de nem respeitar o nível 1... é um pesadelo pra integridade e segurança fazer o front chamar uma dúzia verbos em uma dúzia de recursos... o front não precisa saber que entidades foram alteradas, o que foi criado, o que foi alterado, etc...
Exemplo prático... temos uma gestão de candidatos no nosso sistema... quando alguém se candidata o sistema:
1) Cria um registro de candidato
2) Um candidato pode ter entrado por uma URL com link de indicação, se for o caso notifica o mentor ligado aquela URL de indicação
3) Lança um registro informando que o candidato entrou na fase de Análise Inicial pelo Mentor
Tudo isso é feito em uma única chamada... o front não precisa saber que isso acontece, nem deve saber, nunca que cada um seria um "resource" chamado pelo meu front.
Apesar dessa abordagem ser a correta ao ser referir a rest em aplicações grandes o json ficaria muito grande e na Cloud os dados tem custo para trafegar e foi um dos motivos da criação do GraphQL que é um Post com consulta, não vejo vantagem em expor os link pode dar dicas a atacantes maliciosos
Oi Jorge, tudo bem?
Os dados tendem a ficar maiores sim, mas aí entra um dos pilares do rest que é poder fazer cache com qualquer componente envolvido na arquitetura como browser, proxy cache e outros.
O uso de protocolo http 1.1 e dos cache-control, etag, last-modified servirão para otimizar a comunicação, diminuição a latência e os dados trafegados. Em várias situações, a resposta já estará no browser ou nem vai bater na API, baterá num proxy cache e ainda é possível usar o header etag fazendo com que se a resposta não mudou, só retorna status 304 modified, então o cliente reusa o cache local que ele tinha.
O cache é um dos 5 pilares fundamentados pelo Roy Fielding na dissertação dele. Na verdade o uso de cache deveria ser muito mais comum com http, mas cache é só visto do lado da aplicação, como fazer cache com redis, no banco de dados e etc.
São trade-offs, aumentamos os dados por uma melhor navegabilidade na API que a torna auto-documentada e muitas vezes o grande volume de dados retorno pode ser um mal design dos recursos