show Bruno! Gostaria de fazer uma sugestão, não sei se foi apenas para mim mas achei que a música em background ficou um pouco alta, se pudesse reduzir nos próximos vídeos ficaria mais agradável.
Exatamente. Se, por exemplo, o verbo PUT ou POST não for suficiente claro para expressar uma url amigável, não custa nada escrever um verbo para facilitar o entendimento da chamada.
Muito bom ! Dúvida: Semanticamente falando, o que é certo dizer? 'Os protocolos HTTP utilizam o conceito de REST', ou 'O REST utiliza o protocolo HTTP'?
Pelo REST ser um Estilo Arquitetural ou Design Arquitetural, cujo objetivo é a padronização em como os serviços são desenvolvidos na web, diria a você que o mais correto seria dizer que: o REST não existe sem HTTP, mas o HTTP existe sem REST.
Partindo do principio que o Roy utilizou o paper dele como um guia para o HTTP. Diria que o protocolo HTTP utiliza o conceito de REST. O REST é um conceito, portanto não diria que existe uma dependencia entre ele e o HTTP.
Gostei do conteudo, mas senti falta de uma visao mais objetiva. No exemplo de aprovaçao, na sua visao, deveria ser qual request? POST /candidato/{id}/aprovar-ou-recusar? PUT /candidato/{id}/aprovar-ou-recusar? POST /candidato/{id}/avaliar? Pessoalmente, eu tento colocar nas minhas uri`s acoes no final, pra ser um pouco mais semantico. Mas o http nao é claro quanto a isso. Acho que por isso que tenho gostado cada dia mais da visao do graphQL
Bruno, uma dúvida sobre o acesso à uma API. No cusro da plataforma o Edu ensina a fazer a autenticação via JWT com o login do usuário. Porém, como fica a situação da permissão da API em si? Por exemplo, supondo que criamos uma API para um App e gostaria que somente esse App acessasse, ninguém mais. Existe um login do "chamador", digamos assim? Ou uma forma de restringir quem chama nossa API?
@@henriquepolsani Pensei via CORS, porém é um app, como eu definiria o CORS? Vou analisar a possibilidade de API-KEY, porém nesse caso o chamador teria que passar essa chave + o token do usuário logado, correto?
@@laurolnunes Como o próprio @Henrique Polsani disse, o Api-key é o mais utilizado. Isso só vai mudar dentro de um cenário onde vc tem um servidor de OAuth2, pois há outras opções.
@@laurolnunes Isso ai, api-key + token. Como é um app eu indicaria vc colocar essas Apis em um APIGateway para ter um gerenciamento melhor principalmente com as politicas de segurança e cache. Lembre-se sempre de ter uma conexão TLS e pinnar o certificado no seu aplicativo pro pessoal não sniffar as suas requisições. Uma boa pratica tb seria deixar as suas APIs travadas apenas para consumo através do API Gateway, assim vc garante que ninguem vai acessar sua aplicação diretamente, forçando a passar pelas politicas de segurança do API Gateway. Abraços.
show Bruno! Gostaria de fazer uma sugestão, não sei se foi apenas para mim mas achei que a música em background ficou um pouco alta, se pudesse reduzir nos próximos vídeos ficaria mais agradável.
João, também tive a mesma impressão, mas acho que foi por causa de terem destacado ela com a letra no início, ela impregnou na mente kk
Obrigado pelo feedback. Vamos tomar cuidado na próxima.
@@Trankiliss só reforçando q não impactou em nada a entrega do conteúdo. Parabéns pela didática e pela ajuda q nos dá com seus vídeos!
Opa bacana, o vídeo!
Tenho interesse de saber mais sobre esse tema.
Abraços
Show de bola Bruno! Simples e direto.
Excelente! Conteúdo de primeira e direto ao ponto.
Excelente Bruno!
Parabéns Bruno!
Muito bom o conteúdo! Bora...
Show!
Rafinha Bastos é vc?
Super top
Muito bom
Top d+!!
Caraca, excelente vídeo e abordagem
“Your API is a hall of shame, you give REST a bad name.” hahahahah muito bom.
massa!!
Exatamente. Se, por exemplo, o verbo PUT ou POST não for suficiente claro para expressar uma url amigável, não custa nada escrever um verbo para facilitar o entendimento da chamada.
Muito bom !
Dúvida: Semanticamente falando, o que é certo dizer? 'Os protocolos HTTP utilizam o conceito de REST', ou 'O REST utiliza o protocolo HTTP'?
Pelo REST ser um Estilo Arquitetural ou Design Arquitetural, cujo objetivo é a padronização em como os serviços são desenvolvidos na web, diria a você que o mais correto seria dizer que: o REST não existe sem HTTP, mas o HTTP existe sem REST.
Partindo do principio que o Roy utilizou o paper dele como um guia para o HTTP. Diria que o protocolo HTTP utiliza o conceito de REST. O REST é um conceito, portanto não diria que existe uma dependencia entre ele e o HTTP.
Gostei do conteudo, mas senti falta de uma visao mais objetiva. No exemplo de aprovaçao, na sua visao, deveria ser qual request?
POST /candidato/{id}/aprovar-ou-recusar? PUT /candidato/{id}/aprovar-ou-recusar? POST /candidato/{id}/avaliar?
Pessoalmente, eu tento colocar nas minhas uri`s acoes no final, pra ser um pouco mais semantico. Mas o http nao é claro quanto a isso.
Acho que por isso que tenho gostado cada dia mais da visao do graphQL
Cara, o som de fundo do vídeo estava bem alto, dá pra se perder um pouco no conteúdo por causa do background music muito alto, só uma dica.
You give REST a badname! huahuhuaa muito maneiro a ideia
Bruno, uma dúvida sobre o acesso à uma API. No cusro da plataforma o Edu ensina a fazer a autenticação via JWT com o login do usuário. Porém, como fica a situação da permissão da API em si? Por exemplo, supondo que criamos uma API para um App e gostaria que somente esse App acessasse, ninguém mais. Existe um login do "chamador", digamos assim? Ou uma forma de restringir quem chama nossa API?
Você pode adicionar uma chave de api (api-key) ou travar a origem da fonte chamadora via CORS
@@henriquepolsani Pensei via CORS, porém é um app, como eu definiria o CORS? Vou analisar a possibilidade de API-KEY, porém nesse caso o chamador teria que passar essa chave + o token do usuário logado, correto?
@@laurolnunes Como o próprio @Henrique Polsani disse, o Api-key é o mais utilizado. Isso só vai mudar dentro de um cenário onde vc tem um servidor de OAuth2, pois há outras opções.
@@laurolnunes Isso ai, api-key + token. Como é um app eu indicaria vc colocar essas Apis em um APIGateway para ter um gerenciamento melhor principalmente com as politicas de segurança e cache. Lembre-se sempre de ter uma conexão TLS e pinnar o certificado no seu aplicativo pro pessoal não sniffar as suas requisições. Uma boa pratica tb seria deixar as suas APIs travadas apenas para consumo através do API Gateway, assim vc garante que ninguem vai acessar sua aplicação diretamente, forçando a passar pelas politicas de segurança do API Gateway. Abraços.
@@henriquepolsani muito esclarecedor, obrigado pela resposta! Vou aplicar suas indicações na autenticação dessa minha API, valeu pelas dicas!
CREATE, REMOVE, UPDATE, DELETE em 1:30 kkkk