[MÚSICA]
Deixe-me dar-lhe um breve descanso.
Te peguei lá!
O que eu queria dizer foi,
deixe-me dar-lhe uma breve visão geral da transferência de estado representacional.
O que exatamente é descanso?
Como fazemos uso dele em nossa aplicação angular e
como fazemos uso disso para nos comunicarmos com o servidor?
Como um servidor oferece suporte à API REST e
como acessamos a API REST a partir de nosso aplicativo Angular?
Vamos falar sobre isso um pouco mais nesta lição.
Nesta palestra em particular, lhe darei uma breve visão geral do REST.
Tenho certeza que você já ouviu o termo Serviços Web sendo mencionado
no mundo da TI com muita frequência.
O que exatamente são serviços web?Os serviços Web
são uma forma de projetar sistemas para suportar a interoperabilidade entre os sistemas
conectados através de uma rede, como a Internet, como vemos hoje.
Isso é o que nos referimos como uma arquitetura orientada a serviços.
Agora, o que isso significa é que você fornece uma maneira padronizada para duas máquinas
que estão conectadas à Internet para serem capazes de se comunicar uns com os outros.
Seu nível de layout de aplicativo para aplicativos de banco de dados
usando padrões abertos.
Agora, eu usei um monte de jargão lá.
Vamos tentar dividi-los e
entender um pouco sobre cada um disso nesta palestra.
Duas abordagens comuns que são usadas para suportar serviços Web são SOAP,
os serviços web baseados em protocolo de acesso a objetos simples,
que usa a linguagem de descrição de serviços Web para
especificando como os dois pontos finais se comunicam entre si.
E normalmente, soap é baseado em usar XML como
o formato para as mensagens que estão sendo trocadas entre os dois pontos finais.
A transferência de estado de apresentação ou repouso também usa padrões da web, mas a troca
de dados entre os dois pontos de extremidade pode ser XML ou cada vez mais.
Usando JSON como formato.
A maneira REST de interoperabilidade é mais simples em comparação com SOAP e
, portanto, REST encontrou uma implantação muito mais ampla nos serviços web restantes.
Normalmente, a comunicação do servidor cliente é facilitada usando REST
, onde o servidor oferece suporte à API REST e o cliente pode então invocar seus pontos de extremidade da API REST
para obter informações ou carregar informações para o servidor.
Novamente, Eu mencionei a palavra, invocar esse ponto final da API REST.
Então, estes são alguns termos que eu usei.
Vamos esclarecer alguns desses slides nos próximos slides.
Transferência de estado representacional é um estilo de arquitetura de software que
é especialmente projetado para hipermídia distribuída na World Wide Web.
Agora isso foi introduzido pela primeira vez por Roy Fielding em sua tese de doutoramento.
Agora, esta é uma daquelas tese de doutorado que realmente produziu
algo útil para o mundo.
Então, isso encontrou novamente um monte de 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 pontos de extremidade da API REST.
Dentro da Transferência de Estado Representacional existem quatro princípios básicos de design.
Em primeiro lugar, REST é construído sobre o protocolo HTTP.
Então ele usa todos os métodos HTTP que já vimos na lição anterior.
Segundo, 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 essa conversa
entre o cliente e o servidor.
Em terceiro lugar, a forma REST de fornecer recursos é
expor uma estrutura de diretório como URLs de localizadores de recursos uniformes URLs.
E quarto seu formato para troca de dados é tipicamente JSON ou
XML, ou ambos que podem ser suportados usando REST.
Uma das motivações para subir sugerindo REST como uma forma de apoiar serviços web
é que ele captura tudo o que é bom de toda a World Wide Web.
E isso fez a Word Wide Web bem sucedida.
O uso de Indicadores Uniformes de Recursos ou Localizadores de Recursos Uniformes, URLs,
que permitem que você aborde recursos especificando-os como um URL,
o segundo sendo um protocolo que está no topo do protocolo HTTP.
HTTP já encontrou ampla implantação na Internet.
Terceiro, o ciclo de resposta de solicitação pelo qual HTTP é bem conhecido.
Então você envia uma solicitação, o servidor recebe sua solicitação, processa a solicitação,
envia a resposta para a solicitação, e esse cliente recebe a resposta,
age sobre isso, e pode gerar novas solicitações.
Então, esta abordagem do ciclo de resposta de solicitação é muito bem estabelecida com HTTP
e o protocolo HTTP da Web em todo o mundo como vimos anteriormente,
vamos usar todos os vários verbos que HTTP fornece.
Especificamente, o portão colocar post delete.
Para ser capaz de especificar operações a serem feitas
em recursos que são armazenados no lado do servidor.
Assim, por exemplo, se você fizer uma solicitação HTTP GET, você está pedindo
o servidor para retornar a origem.
Se você fizer uma solicitação POST, você está 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 de exclusão, você está pedindo
o servidor para excluir o recurso identificado por esse URL específico.
Além disso, ele tenta preservar a idempotência.
Algumas operações quando são executadas
Mesmo repetidamente não causarão qualquer alteração 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 consequências prejudiciais.
E que tem que ser feito 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.
Substantivos, especificamente, eles estão cheios de recursos e
esses recursos geralmente são identificados por seus URLs e estes são irrestritos.
Verbos são restritos e essas ações especificadas devem ser feitas nos recursos.
E as apresentações como vemos quando as informações precisam ser transmitidas de
o servidor para o cliente ou
do cliente para o servidor, como você codifica as informações.
Normalmente usando JSON ou usando XML.
Resource é a abstração chave que o REST trabalha em torno de modo
que as informações são abstraídas no recurso.
E o recurso é identificado especificando-o usando um URI.
Assim, qualquer informação que possa ser encapsulada e
ser disponibilizada pode ser identificada como um recurso.
Uma informação como esse clima atual em Hong Kong pode ser um recurso,
uma imagem pode ser um recurso.
Uma informação sobre o preço das ações pode ser um recurso, e assim por diante.
Portanto, tudo o que você definir como uma 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 esse servidor pode enviar para esse cliente.
Um exemplo de como você nomeia recursos é ilustrado aqui.
Então usamos URIs para identificar a fonte.
Uma leitura rápida da especificação ou dos URLs aqui irá
facilmente permitir que você entenda o que estamos nos referindo usando esses URLs.
Assim, por exemplo, algo que termina com pratos/,
você automaticamente assume que isso está se referindo a uma coleção de pratos.
Como pratos/123 por exemplo,
pode significar prato número 123, neste caso e assim por diante.
Portanto, é muito fácil dizer que você pode especificar uma coleção de recursos, e
ser capaz de identificá-los como uma coleção, e depois baixá-los como uma coleção.
Ou você pode identificar um recurso individual e
dizer que deseja esse recurso específico.
Agora esses recursos podem ser organizados em uma hierarquia
que a especificação deste URI.
Então, à medida que você atravessa o caminho,
você vai do mais geral para o mais específico desse recurso.
Esta estrutura de diretórios permite identificar facilmente os recursos que
você fornece do seu site de serviço.
A segunda parte da API REST são as palavras.
Em particular, estamos interessados nos 4 verbos de HTTP para obter,
colocar, postar e excluir.
Neste caso, esses verbos serão cochilados para ações que
queremos que sejam executadas no recurso no lado do servidor.
GetT significaria que você deseja executar uma operação de leitura no recurso, o que significa
que um cliente enviando uma solicitação get está indicando ao servidor que ele deseja
obter essa apresentação da fonte de dados do site do servidor para o site do cliente.
POST significa que você deseja criar um novo recurso e então você vai.
Especifique os detalhes do recurso na representação, mas é usado para
especificar o recurso.
Em seguida, envie as informações para o lado do servidor, para
que o servidor irá criar o recurso em seu nome.
Um PUT seria modificação de recursos, e
delete, como você esperaria, é exclusão das fontes.
Então, como você pode ver os quatro verbos obter, postar, colocar e
delete são mapeados para as quatro operações CRUD que você pode executar
em um banco de dados que armazena esses recursos no lado do servidor.
As operações de leitura, criação, atualização e exclusão.
Elaborando mais, o HTTP GET é uma maneira de especificar.
Que você deseja que as informações ou sua apresentação do recurso sejam
retornadas ao cliente a partir do site do servidor.
Então, quando você emite uma solicitação GET para um endpoint da API REST.
Você está pedindo uma coleção de recursos que são apresentados por
Uri ou um recurso específico que é identificado pelo ID de
que recursos específicos especificados dentro da URL assim como você vê neste exemplo,
se você pratos/452, você está querendo dizer que o prato número 452,
com o id 452 deve ser devolvido ao lado do cliente.
Da mesma forma, a operação de 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 isso seria
incluído no corpo da mensagem de solicitação que é enviada para o lado do servidor.
Portanto, uma operação de postagem espera uma representação
do recurso no formato JSON ou XML no corpo da mensagem de solicitação.
E o servidor recebe essa mensagem de solicitação, o servidor cria esse recurso
no lado do servidor e retorna uma confirmação ou
um erro para indicar que a criação do recurso falhou.
Da mesma forma ele colocar operação fácil de usar 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 o recurso específico no corpo da mensagem de resposta.
Ou você pode enviar a representação completa do recurso
no corpo da mensagem, dependendo do arranjo entre o cliente e
o servidor, o servidor espera que as informações sejam
transmitidas no corpo da mensagem de solicitação.
operação DELETE como você esperaria exclui o recurso existente.
Agora, neste caso particular, é claro, uma operação de exclusão seria 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, é um exemplo de uma operação neste caso.
Da mesma forma, a operação get também funcionará porque não é
fazendo qualquer modificação no recurso no site do servidor.
Entrada de postagem, é claro, vai modificar o recurso no lado do servidor.
Você precisa criar um novo recurso ou
modificar recurso existente no lado do servidor e, claro, apresentações de dados.
Como eu tenho enfatizado, os dois fallbacks comuns para
representando é JSON XML, a última parte
que precisamos enfatizar é que o lado do servidor deve ser completamente apátrida.
O que significa, que o lado do servidor não rastreia o estado do cliente.
Porque, se o servidor precisar rastrear o estado do cliente, ele não será escalável.
Assim, para uma implementação escalável do lado do servidor,
você normalmente usa um servidor sem estado no lado do servidor.
Portanto, se a solicitação dos clientes enviados para o servidor será tratada como
uma solicitação independente, e não refletirá sobre as solicitações
anteriores que já foram tratadas pelo servidor do cliente específico.
Portanto, é responsabilidade do cliente rastrear seu próprio estado.
Ou na forma de usar cookies ou usar um banco de dados do site do cliente.
O que quer que signifique que é adequado.
Agora, essa abordagem em que o cliente rastreia seu próprio estado é muito mais escalável,
porque seu cliente será responsável por rastrear o seu próprio estado.
E é aqui que a configuração do lado do cliente MVC nos ajuda a este respeito.
E, finalmente, ainda não terminamos com REST, veremos mais de
REST nos exercícios que se seguem nesta lição particular.
E então também,
vamos ver mais detalhes sobre o uso REST no resto deste curso.
[MÚSICA]