Deixe-me dar-lhe um breve descanso. Apanhei-te lá.
O que eu queria dizer foi deixe-me dar-lhe
uma breve visão geral da Transferência Estadual Representacional.
O que exatamente é REST?
Como fazemos uso dele em nosso aplicativo React,
e como fazemos uso disso para nos comunicarmos com o servidor?
Como um servidor oferece suporte à API REST
e como acessamos a API REST do nosso aplicativo React?
Vamos falar sobre isso um pouco mais nesta lição.
Tenho certeza que você já ouviu o termo serviços da Web sendo mencionado no mundo da TI com muita frequência.
O que são exatamente serviços da Web?
Serviços Web são uma forma de projetar sistemas para suportar a interoperabilidade
entre os sistemas que estão conectados através de uma rede como a Internet, como vemos hoje.
Isso é o que chamamos de arquitetura orientada a serviços.
Agora, o que isso significa é que você fornece
uma maneira padronizada para que duas máquinas conectadas à internet possam
se comunicar entre si no
nível da camada de aplicativo para aplicativos baseados na Web usando padrões abertos.
Agora, eu usei muito jargão lá.
Vamos tentar dividi-los e entender
um pouco sobre cada um deles nesta palestra.
Duas abordagens comuns que são usadas para suportar serviços Web são SOAP.
Os serviços Web baseados no Simple Object Access Protocol que usa
a linguagem de descrição de serviços Web para
especificar como os dois pontos finais se comunicam entre si.
Normalmente SOAP é baseado no uso de XML como
o formato para as mensagens que estão sendo trocadas entre os dois pontos finais. A
Transferência de Estado Representacional ou REST também usa padrões web,
mas a troca de dados entre os dois pontos finais pode ser XML ou
cada vez mais usando JSON como o formato.
A forma REST de interoperabilidade é mais simples em comparação com SOAP e, portanto, a
REST encontrou uma implantação muito mais ampla no mundo dos serviços web.
Normalmente, a comunicação cliente-servidor é
facilitada usando REST, onde o servidor oferece suporte
a uma API REST e o cliente pode invocar os pontos finais da API REST
para obter informações ou carregar informações para o servidor.
Novamente, mencionei a palavra invocar os pontos finais da API REST,
então estes são alguns termos que usei.
Vamos esclarecer alguns destes nos próximos slides.
Representational State Transfer é um estilo de arquitetura de software
que é especialmente projetado para hipermídia distribuída através da World Wide Web.
Agora isso foi introduzido pela primeira vez por Roy Fielding em sua tese de doutorado.
Agora esta é uma daquelas teses de doutorado
que realmente produziu algo útil para o mundo.
Então isso encontrou novamente muita tração no mundo dos serviços web.
Esta é uma coleção de princípios de rede que descrevem como
os recursos podem ser disponibilizados em servidores
e esses recursos podem ser acessados a partir de clientes,
identificando os recursos usando endpoints de API de descanso.
Dentro da Transferência Estadual Representacional,
existem quatro princípios básicos de concepção.
Primeiro e acima de tudo, REST é construído sobre o protocolo HTTP,
por isso ele usa todos os métodos HTTP que já vimos na lição anterior.
Em segundo lugar, REST foi projetado para ser apátrida,
o que significa que o servidor não armazena nenhuma informação sobre
o estado após a comunicação ser concluída.
Então, quando um servidor recebe a solicitação, o servidor responde,
e depois disso ele não se lembra de
nada mais sobre a conversa entre o cliente e o servidor.
Terceiro, a maneira REST de fornecer recursos é
expor uma estrutura de diretórios como URLs (Uniform Resource Locators - URLs).
Em quarto lugar, o formato para troca de dados é tipicamente JSON
ou XML ou ambos podem ser suportados usando REST.
Uma das motivações para Roy sugerir REST como uma forma de apoiar serviços web é
que ele captura todas as coisas que são boas sobre
a World Wide Web e que fez a World Wide Web bem sucedida.
O uso de Indicadores Uniformes de Recursos ou
URLs (Uniform Resource Locators, Localizadores Uniformes de
Recursos) que permitem que você aborde recursos especificando-os como um URL.
O segundo, sendo um protocolo que vive em cima do protocolo HTTP.
HTTP já encontrou ampla implantação na internet.
Em terceiro lugar, o ciclo de resposta de solicitação que HTTP é conhecido para.
Então você envia uma solicitação,
o servidor recebe sua solicitação, processa a solicitação,
envia a resposta à solicitação,
e o cliente recebe a resposta,
age sobre isso, e pode gerar mais solicitações.
Então, essa abordagem do ciclo de resposta de solicitação é muito
bem estabelecida com HTTP e a World Wide Web.
Agora, o protocolo HTTP como vimos anteriormente,
vamos usar todos os vários verbos que HTTP fornece.
especificamente, o GET, PUT,
POST e DELETE
para ser capaz de especificar operações a serem feitas em recursos que são armazenados no lado do servidor.
Então, por exemplo, se você fizer uma solicitação HTTP GET,
você está pedindo para o servidor para retornar o recurso.
Se você fizer uma solicitação POST,
estará solicitando que o servidor crie um novo recurso.
Se você fizer uma solicitação PUT,
você está solicitando que o servidor atualize um recurso existente.
E se você emitir uma solicitação DELETE,
você está solicitando
que o servidor exclua o recurso identificado pelo URL específico.
Além disso, tenta preservar a Idempotência.
Algumas operações, quando são realizadas mesmo repetidamente,
não causarão nenhuma mudança de estado.
Algumas outras operações, se você as fizer sucessivamente,
elas podem causar uma mudança de estado.
Então você precisa ter cuidado com quais operações podem ser repetidas sem
quaisquer conseqüências prejudiciais e que devem ser feitas com muito cuidado.
No mundo REST, muitas vezes você ouve pessoas falando sobre substantivos, verbos e representações.
Agora, vamos esclarecer cada um deles com um pouco mais de detalhes nos próximos slides.
Os substantivos se referem especificamente a recursos e esses recursos são
geralmente identificados por suas URLs e estes são irrestritos. Os
verbos são constrangimentos e estes especificam as ações a serem
feitas sobre os recursos e representações como vemos.
Quando as informações precisam ser transmitidas
do servidor para o cliente ou do cliente para o servidor,
como você codifica as informações.
Normalmente, usando JSON ou usando XML.
Recurso é a abstração chave que REST trabalha.
Assim, as informações são abstraídas na forma de um recurso e o recurso
é identificado especificando-o usando uma URL.
Assim, qualquer informação que possa ser encapsulada e disponibilizada,
pode ser identificada como um recurso.
Um pedaço de informação como o tempo atual em Hong Kong poderia ser um recurso,
uma imagem poderia ser um recurso,
uma informação de preço de ações poderia ser um recurso e assim por diante.
Então, o que quer que você defina como um pedaço de informação que um cliente pode estar interessado,
pode ser identificado como um recurso.
Você pode até mesmo lidar com recursos como coleção de
recursos que o servidor pode enviar para o cliente.
Um exemplo de como você nomeia recursos é ilustrado aqui.
Então usamos URIs para identificar a fonte.
Uma leitura rápida dessas especificações ou dos URIs aqui
permitirá que você entenda facilmente o que estamos nos referindo usando esses URIs.
Assim, por exemplo, algo que termina com pratos/,
você assume automaticamente que isso está se referindo a uma coleção de pratos.
Mas pratos/123, por exemplo,
pode significar prato número 123 neste caso e assim por diante.
Então, é muito fácil de salvar e você pode especificar
uma coleção de recursos e ser capaz de
identificá-los como uma coleção e, em seguida, baixá-los como uma coleção ou você pode
identificar um recurso individual e dizer que você quer esse recurso em particular.
Agora, esses recursos podem ser organizados em uma hierarquia da especificação deste URI.
Então, à medida que você percorre o caminho,
você vai do mais geral para o mais específico do recurso.
Essa estrutura de diretórios permite que você identifique os recursos
que você usa ou fornece do lado do servidor com muita facilidade.
A segunda parte da API REST são os verbos.
Em particular, estamos interessados nos quatro verbos de HTTP GET,
PUT, POST e DELETE.
Nesse caso, esses verbos serão mapeados em ações que
queremos que sejam executadas no recurso, no lado do servidor.
Um GET significaria que você deseja executar uma operação de leitura no recurso.
Então, o que significa que um cliente enviando uma solicitação GET está indicando ao servidor que ele
deseja obter uma representação
desse recurso do lado do servidor para o lado do cliente.
Um POST significa que você deseja criar
um novo recurso e, em seguida, você especificará os detalhes do recurso
na representação que é usada para
especificar o recurso e, em seguida, enviar essas informações para o lado do servidor, de
modo que o servidor criará esse recurso em seu nome.
Um PUT seria modificação de recursos e
um DELETE como você esperaria é a exclusão dos recursos.
Assim, como você pode ver, os quatro verbos;
GET, POST, PUT e DELETE,
são mapeados para as quatro operações CRUD que você pode
realizar em um banco de dados que armazena esses recursos no lado do servidor, as
operações READ, CREATE, UPDATE e DELETE.
Elaborando ainda mais, o HTTP GET é uma maneira de especificar que você
deseja que as informações ou a representação
do recurso para ser retornada para o cliente do lado do servidor.
Então, quando você emite uma solicitação GET para um ponto final da API REST,
você está pedindo uma coleção de recursos representados por
URI ou um recurso específico que é identificado pelo ID desse recurso específico,
especificado dentro da URL.
Então, como você vê neste exemplo,
se você diz, pratos/452,
você está querendo dizer que o prato número 452 com
a ID 452 deve ser retornado para o lado do cliente.
Da mesma forma, a operação POST como vimos é usada para criar o recurso.
Então, quando você cria o recurso,
o conteúdo de descrever o recurso seria na forma de uma representação JSON ou
uma representação XML e que será incluído no
corpo da mensagem de solicitação que é enviada para o lado do servidor.
Assim, uma operação POST espera uma representação
do recurso no formato JSON ou XML no corpo da mensagem de solicitação.
Quando o servidor recebe essa mensagem de solicitação,
o servidor cria esse recurso no lado do servidor e retorna
uma conformação ou um erro para indicar que a criação do recurso falhou.
Da mesma forma, uma operação PUT é usada para atualizar um recurso.
Quando você faz uma operação PUT em um recurso no lado do servidor,
você pode enviar de volta a modificação,
especificando apenas a modificação parcial que você deseja afetar sobre
o recurso específico no corpo da mensagem de resposta ou você pode enviar
a representação completa do no corpo da mensagem.
Dependendo da organização entre o cliente e o servidor,
o servidor espera que as informações sejam transmitidas no corpo da mensagem de solicitação.
Uma operação DELETE como seria de esperar exclui o recurso existente.
Agora, neste caso particular,
é claro que uma operação DELETE seria idempotente porque se você
tentar excluir um recurso e o recurso existir, ele será excluído.
Se você estiver tentando excluir um recurso não existente,
ele não causará nenhuma modificação adicional no lado do servidor,
exceto que o servidor responderá com um erro dizendo que o recurso não existe.
Mas, no entanto, DELETE é um exemplo de uma operação idempotente neste caso.
Da mesma forma, a operação GET também é uma operação idempotente porque
não está fazendo quaisquer modificações para o recurso no lado do servidor.
POST e PUT, é claro, vão modificar o recurso no lado do servidor,
ou criar um novo recurso ou modificar um recurso existente no lado do servidor.
Claro, as representações,
como eu tenho enfatizado,
os dois formatos comuns para representar é JSON ou XML.
A última parte que precisamos enfatizar é
que o lado do servidor deve ser completamente sem estado, o
que significa que o lado do servidor não rastreia
o estado do cliente porque se o servidor precisa rastrear o estado dos clientes,
ele não será escalável.
Então, para uma implementação escalável do lado do servidor,
você normalmente usa um servidor sem estado no lado do servidor.
Assim, cada solicitação que o cliente envia para o servidor será
tratada como uma solicitação independente e
não refletirá sobre solicitações anteriores
que já foram tratadas pelo servidor desse cliente específico.
Portanto, é responsabilidade do cliente rastrear seu próprio estado,
seja na forma de usar cookies ou usando um banco de dados do lado do cliente,
seja qual for o meio adequado.
Agora, essa abordagem em que o cliente rastreia seu próprio estado é
muito mais escalável porque cada cliente individual
será responsável por rastrear seu próprio estado.
Este é o lugar onde a configuração MVC do lado do cliente nos ajuda a este respeito.
Finalmente, ainda não terminamos com REST.
Veremos mais de REST nos exercícios que se seguem nesta lição particular
e, em seguida, também veremos mais detalhes sobre o uso de REST no resto deste curso.