Resumo sobre REST

O que é REST? No inglês, representational state transfer, transferência de estado representacional. O que é REST? O REST é uma maneira de se escrever um API. API Application Programming Interface. O padrão REST é um dos mais populares hoje para se escrever um API no lado do servidor. E quais são os pontos principais de um API REST? Então, vamos falar disso. Então, tem que haver uma separação entre o cliente e o servidor. Essa separação tem que ser clara. Outro fator é, não pode haver a existência de estado nessa transferência de servidor ao cliente. É o conceito no inglês stateless sem estado. Não significa que você não pode armazenar as coisas. Claro que pode. Coisas ficam armazenadas no banco de dados do servidor. Mas essa transferência, essas mensagens que são trocadas, só se tem mensagem sobre o recurso. Por exemplo, você tem uma livraria. Então, o recurso é livro. Então, há várias operações no livro. A gente pode criar um recorde de um livro, pode alterar um recorde, pode delatar um recorde, ou pode obter uma lista de todos os records. Então, há uma operação e um recurso. Isso diz o servidor que fazer. Claro que dá para fazer as coisas. Mas quem armazenar os negócios, quando o servidor pega as informações, ele vai, ok, você quer que eu crie um recurso, e você me deu as informações do recurso a ser criado. E o servidor vai fazer essa operação. Mas depois que termina essa operação do lado do servidor, ele não vai armazenar nenhum estado para saber... Assim, ele termina a operação, pronto, terminei. Vou para a próxima operação, não importa quem. Não armazenar metodia, estado nesse sentido. Claro que a gente pode autenticar, pode autorizar e fazer tudo isso. Mas a sessão em si própria não é armazenada no corpo, assim se dizer, da transferência. Normalmente se usa tokens, que a gente passa no header de HTTP chamado authorization. Então, como a gente acabou de falar de recursos, tem essa interface que é uniforme e padrão de uma espécie de hierarquia de recursos, que você identifica os recursos através da URL do caminho. Por exemplo, no caso dos livros, se a gente quiser obter uma lista de livros, a gente usaria o verbo get, o método get de HTTP, seguido do caminho barra livros. Então, o verbo, que é get, também chamado de método, HTTP, aqui identifica a operação de obter alguns dados. Nesse caso, barra livros é o recurso. Nesse caso, seria a lista de recursos no plural. Então, o get barra livros é usado para obter uma lista de livros, de recordes de livros. Agora, se você quiser criar um recorde de livros, em vez de obter, você muda o verbo. Nesse caso, vai de get para post. Então, para poder criar um livro através dessa API, você utilizaria post barra livros. Para poder obter só um livro específico, você pode usar o verbo get, seguido do barra livros, barra um identificador do livro. Normalmente, o id do banco de dados, do livro, id do livro. Isso aparece só no caminho. Então, para poder obter informações de um certo livro específico, o get barra livros, barra um, dois, três, por exemplo, onde um, dois, três é o id do livro. Então, você vê uma hierarquia, lá da esquerda, o nome do recurso, barra o id específico de um recurso específico. E esse lance de hierarquia também pode adicionar mais e mais caminhos e a coisa se torna mais específica. Por exemplo, no exemplo do livro, eu posso pensar também de exemplo de autores. Então, se eu quiser acessar uma lista de autores, seria o caminho get, o caminho do barra autores. Se eu quiser um ator específico, o barra autores, o barra o id do autor. Se eu quiser saber os livros desse autor, eu posso dizer, por exemplo, a get barra autores, barra um, dois, três, onde um, dois, três é o id do autor, barra livros. Nesse caso, o barra autores, barra um, dois, três, barra livros, nos daria a lista de livros que são associados ao autor. Então, se eu fosse em um caso e seria os livros que foram escritos pelo autor, então você vê que na hierarquia, no lado mais esquerdo, é o dono de alguma coisa, e aí fica mais específico do lado direito. Você vê que os livros pertencem ao coisa do lado esquerdo, que é o autor. Então, também essa hierarquia que você pode fazer mais e mais, mais e mais. Mas, normalmente, se tiver muita, fica pesado. Normalmente, a gente tem no máximo dois níveis. Se formar de um nível, é melhor você cortá-lo da esquerda e deixar só o que é principal mesmo. Outro fator de uma API REST é que quando você conversa com o servidor, a API, através de REST, no caso do REST, o cliente não precisa saber da implementação do servidor. Ele só precisa saber da interface, das operações através da interface. Isso é um conceito comum da media API. Então, se o servidor usa linguagem A ou B, ou se o servidor chama outro servidor, ou chama esse banco de dados, para isso, o cliente não importa para o cliente como o servidor vai processar as coisas. O que importa é que eu te dou uma entrada, o servidor me dá saída. Só isso, o cliente só vai saber disso, não vai saber de nada específico do lado do servidor, de como ele faz aquela operação. Tá bom, pessoal? Então, eu acho que os mais importantes para saber a separação entre cliente e servidor, você não pode manter o estado. O estado, o status, tem também o lance de ter... ...da negócio de cache, que é para poder economizar na banda larga. Nesse caso, tem também que ter a API REST, deve ter uma habilidade para você fazer cache. Cache significa que se você faz o mesmo pedido para a mesma coisa, mais de uma vez, a mesma entrada e a mesma saída, e a mesma coisa repetida, repetida, repetida, em vez de você sempre fazer a mesma coisa, tem que ter uma maneira de fazer cache, porque para que você não precise fazer o mesmo processamento de novo, de novo, de novo, de novo, e você já fez uma vez e é só mandar essa resposta repetida, sem precisar gastar com o processamento novamente. Tem também esse lance de habilidade de criar cache. A Monta também olhamos na negócio do lance da interface uniforme, que é a hierarquia dos recursos, esse conceito da identificação do recurso através do caminho da URL, usando um método de HTTP, também chamado verbo, nesse caso, deixa eu te dizer de novo os verbos, eu acho que eu esqueci de dizer o delet e o put. Então, por exemplo, no exemplo dos livros, obter todos os livros, get, barra, livros. Obter um livro específico, get, barra, livros, barra, ID do livro. Criar um livro, post, barra, livros. Deletar um livro, delet, que é o método, delet, barra, livros, barra, ID do livro. Para poder alterar ou substituir um livro. Put, que é o verbo, put, barra, livros, barra, ID do livro. P, t, put, para poder criar ou substituir, nesse caso, alterar, por si como um todo. Tem também o patch, que o patch é mais específico de você alterar, só uma parte do recurso. Normalmente se usa mais put, mas se você quiser também pode usar patch. Nesse caso, seria na mesma maneira de alterar, mas só uma parte específica. Put, barra, livros, barra, ID do livro. Patch, barra, livros, barra, ID do livro. Certo? Tá bom, então temos get, post, put, delete, patch, como os métodos de HTTP. E tem o caminho, dependendo do caminho você precisa adicionar o identificador ou não. No caso de criar um livro, não precisa de identificar o identificador. No caso de obter todos os livros, não precisa. Só no caso de uma coisa bem específica que você adiciona o barra, ID do recurso, aí, imediatamente a sua esquerda no caminho. Também olhamos o lance da abstração, que o cliente não precisa saber da implementação específica do servidor. E um lance mais próprio terminar, também opcionar, mas não é um ponto muito... que a gente se lembra muito não, pode também mandar a código. O servidor pode transferir código a ser executado no cliente, por exemplo, JavaScript. Tá bom, então, por isso é só rest, representational, state transfer, transferência de estado representacional, uma maneira de você criar sua API, Application Programming Interface. É um dos métodos mais populares hoje, senão o mais popular de se escrever API, que todo mundo, quando você vê o API, já vê que tem os lanços do recurso no caminho, e os verbos de HTTP hoje já sabem, acho que está usando rest, deve estar usando rest. Então, todo mundo já entende, é o padrão que familiar com muitos e permite a gente identificar API, e já usar API de maneira bem rápida, né? Você já sabe na hora, oh, rest, eu já sei que os verbos não são esses, os caminhos são esses, e o deduzo que são esses devem ser esses, porque estão seguindo o padrão rest. Então, por essa... é só, espero que tenham gostado e até a próxima.