Comunicação de serviços e conceito de API REST
- 24-07-2022
- Toanngo92
- 0 Comments
Mục lục
Introdução à API REST
REST é uma arquitetura stateless , REST é usado para construir uma aplicação que se comunica pela rede, inventada e introduzida em 2000, fornecendo um protocolo para comunicação do lado da máquina, cliente e servidor. Na maioria dos casos, essa arquitetura usa um protocolo chamado Hypertext Transfer Protocol (HTTP) para comunicação entre dispositivos.
Antes da introdução da arquitetura REST, os programadores usavam arquiteturas de comunicação complexas com conceitos básicos como:
- Simple Object Access Protocol (traduzido aproximadamente como protocolo básico de acesso a objetos) é abreviado como SOAP . Veja mais aqui
- Remote Procedure Call (chamada de procedimento remoto) é abreviada como RPC . Veja mais aqui
- Common Object Request Broker Archittechture é abreviado como COBRA . Veja mais aqui
Entendemos temporariamente que REST é uma arquitetura leve usada para serviços da web. Com muitas perspectivas diferentes, a WWW (world wide web) baseada no protocolo http trouxe uma arquitetura baseada em REST. O REST é realmente ótimo para a Internet, pois os aplicativos que usam o protocolo http ainda são populares e poderosos. (Se você não entender, imagine quando você digitar o nome de domínio web888.vn no navegador, o navegador adicionará automaticamente http:// ou https:// na frente da string do nome de domínio, além disso, alguns sites adicionam http :/ /www.tenmien.com, isso significa que o navegador define o protocolo http como padrão ao acessar o aplicativo da web)
O REST responde a uma solicitação do lado do cliente em quatro operações conceitualmente denominadas Create,Read,Update,Delete (CRUD). Um aplicativo RESTful envia solicitações HTTP (solicitações) que são usadas para ler, adicionar, atualizar ou excluir dados. Em suma, REST fornece uma arquitetura de fácil compreensão para que possamos manipular e personalizar os dados como queremos e é fornecido como um recurso de biblioteca padrão em linguagens como C#, Java, Perl..
Embora essa arquitetura REST seja bastante abrangente, ou seja, fornece recursos completos, pode ser chamada de fazer tudo, mas essas coisas podem ser feitas através do que é chamado de Web services (serviços da Web), REST não recomendado pelo W3C e não o mecanismo padrão
Princípios REST
O estilo REST é definir um conjunto de restrições usadas para criar uma arquitetura comumente usada, essas restrições são os princípios ou características que diferenciam as arquiteturas REST de outras arquiteturas.
- Comunicação cliente-servidor : basicamente dividido em 2 camadas: cliente e servidor são 2 componentes separados, aplicação RESTful garante que funcionem e ajuda cliente (cliente) a se comunicar com servidor (servidor).
- Statelessness : as informações de estado do cliente não são armazenadas no servidor. Em outras palavras, cada solicitação do lado do cliente incluirá todas as informações necessárias, o servidor recebe as informações e executa a tarefa. Ele permite que o servidor entenda as tarefas do lado do cliente, o estado de cada sessão de comunicação e os dados retornados ao cliente também incluem informações de sessão para cada solicitação (consulta). Steless ajuda a fornecer um mecanismo rígido de comunicação entre o servidor e o cliente para atingir a finalidade da tarefa
- Capacidade de cache: o cliente pode armazenar em cache os dados retornados temporariamente e descrever por si mesmo se os dados podem ser armazenados em cache ou não, se for o caso, os dados serão reutilizados para a próxima resposta, ajudando a aumentar o tempo de resposta
- Interface Uniforme : Uma interface padrão que facilita a interação com todos os componentes, o que simplifica a interação com diferentes serviços. Também ajuda a garantir que as alterações de desenvolvimento não afetem outros componentes do aplicativo, por outro lado, não é possível modificar o padrão.
- Sistema em camadas : um intermediário, como um proxy, que pode interromper a comunicação entre o cliente e o servidor para uma finalidade específica, como segurança, balanceamento de carga ou armazenamento em cache. E o cliente não saberá se está se comunicando com o servidor ou com um intermediário
- Código sob demanda : esta é uma restrição arbitrária em que o servidor estende temporariamente a funcionalidade do cliente, permitindo que ele baixe programas, que são executados no cliente. Por exemplo, um cliente pode executar código javascript para interagir com outro serviço executado nele
Comparar REST e SOAP
Muitos programadores (inclusive eu) perguntam por que REST é mais apropriado que SOAP, é muito difícil para iniciantes porque hoje em dia raramente temos acesso a SOAP. Primeiro, é praticamente impossível comparar REST e SOAP diretamente, porque SOAP é um protocolo e REST é um estilo de arquitetura.
No entanto, os pontos que nos ajudam a avaliar entre SOAP e REST são os seguintes:
Ponto de diferença | SABÃO | DESCANSO |
Coerência entre implementações de cliente e servidor | Amarrado ao servidor, por exemplo, um aplicativo de computador personalizado, um contrato apertado, que pode ser entendido como um vínculo, existe entre o cliente e o servidor, se um deles mudar, tudo no processo de comunicação será quebrado | Um mecanismo fracamente acoplado, como um navegador, um cliente REST é um aplicativo cliente que compartilha métodos e protocolos padronizados comuns aos quais o aplicativo se adapta. Nenhum método adicional é definido para violar os padrões do protocolo. as alterações são tratadas com mais facilidade |
Orientação | Sujeito | Recursos |
Tamanho | Pesado | Leve |
Status | Stateful | Sem estado |
Padrão | Padrões de dados claros | Os padrões de dados não são claros |
Rapidez | Mais lento e consome mais recursos e largura de banda por comunicação | Mais rápido, consumindo menos largura de banda e recursos |
Padrões de comunicação | Linguagem de marcação eXtensible (XML) | Use o controle de mensagens para interpretar com muitas estruturas de dados modernas, como XML, texto simples, JSON |
implementação | Mais complicado (difícil) | Mais fácil |
Cliente | É necessário ter um entendimento completo das arquiteturas de dados em uso antes de interagir | Nenhum conhecimento de API é necessário, exceto o ponto de entrada e o tipo de dados de retorno |
Recursos em Web Services RESTful
Um RESTful Web Service é um negócio de comunicação (serviço) em tecnologia web que evoluiu a partir da arquitetura da API REST. Possui URIs ( Uniform Resource Identifier ) predefinidos, que se referem ao negócio para instruir métodos HTTP.
Na API RESTful, todos os problemas estão em torno do conceito (resource) pode ser traduzido como resource, podemos entender da seguinte forma: toda vez que implementamos métodos api diretivas, trabalhamos com resource, pode ser um documento, imagem, arquivo, web page …. Um recurso possui um tipo (pode ser visualizado como dados) contendo dados dentro dele, e possui uma coleção de métodos para manipulá-lo e possivelmente ter relacionamentos com outros recursos.
Resource em REST é equivalente ao conceito de objeto em linguagens de programação orientadas a objetos, como no problema de gerenciamento de alunos, adicionando, editando e excluindo clássicos em linguagem de programação C, cada variável representa a estrutura de dados do aluno (incluindo nome, idade, série ), em linguagens de programação modernas com nova sintaxe de estilo, é um objeto. E para adicioná-los e removê-los, o REST fornece alguns métodos básicos com conceito CRUD para nós abordarmos. No entanto, na prática, podemos usar mais métodos, mas geralmente os 4 métodos a seguir são suficientes e suficientes para usar:
- POST (Criar): inicializar um novo recurso ou em algumas situações também pode ser usado para atualizar um recurso existente
- GET:(Read) obtém um recurso somente leitura, normalmente usado para obter um objeto ou uma lista de objetos.
- PUT:(Atualizar) atualiza os recursos disponíveis
- DELETE: (Excluir) excluir recurso
Os recursos (Recurso) podem ser completamente agrupados em uma lista, cada lista também é um recurso (Recurso), pode ser entendido como tal, esta lista não pode ser classificada e possui uniformidade, estrutura de dados padrão e podemos usar esses dados para processamento posterior em linguagens de programação, como analisar em arrays, normalizar para tipos de dados primitivos, exibir interfaces de usuário .. ..
Um servidor REST permite o acesso aos recursos e o cliente os representa, cada recurso possui um identificador único baseado no URI padrão (geralmente um parâmetro, slug – um elemento do caminho de transmissão). Por exemplo, um endpoint api como mostrado para representar um endpoint trabalhando com um recurso para gerenciar tarefas (pode ser entendido como um objeto):
Para representação de recursos, o REST oferece suporte a uma variedade de estruturas de dados, desde estritas (XML) até modernas (JSON) ou apenas texto simples (PLAINTEXT). Atualmente e no futuro próximo, o JSON ainda é o mais popular ao usar serviços da web.
Mensagens HTTP
Podemos entender as mensagens HTTP como mensagens de resposta ao se comunicar com HTTP, o serviço Web RESTful depende do HTTP para iniciar comunicações ou emitir mensagens quando o cliente se comunica com o servidor. Durante o processamento da mensagem, o cliente envia uma solicitação HTTP para o servidor, o servidor retorna ao cliente um pacote chamado Resposta HTTP, a mensagem de solicitação e resposta contém o conteúdo da mensagem (mensagem) com informações sobre os dados, denominados metadados. A estrutura é a seguinte:
Estrutura de solicitação HTTP
- Verbo : representa métodos HTTP como GET,DELETE,PUT,POST
- URI : pode ser entendido grosso modo como o caminho de destino, identificando o recurso desejado para trabalhar no servidor
- Versão HTTP : representa a versão do HTTP (por exemplo, v1.1)
- Request Header : contém os metadados do arquivo, com pares de chave-valor padrão. Por exemplo, os metadados adicionam informações ao navegador de solicitação, configuração de cache e formato do corpo da mensagem.
- Corpo da solicitação : contém os dados da mensagem no formato apropriado
Estrutura de resposta HTTP
- Versão HTTP : representa a versão do HTTP (por exemplo, v1.1)
- Código de resposta : 3 caracteres alfanuméricos indicando o status do recurso solicitado. Por exemplo, 200 está ok, 404 é um recurso não encontrado
- Cabeçalho de resposta : possui metadados com mensagem de resposta com pares de valores-chave, por exemplo, a tag de metadados pode incluir comprimento do conteúdo, data de resposta, tipo de servidor, tipo de conteúdo
- Corpo da resposta : contém os dados do arquivo com o formato apropriado
Exemplo de imagem do cabeçalho da solicitação,
Código de resposta | Notificar | Descrever |
200 | OK | Bem sucedido |
201 | Criada | Indica que o recurso desejado foi criado ou atualizado com sucesso por meio do método PUT ou POST e retorna uma conexão com ele por meio do cabeçalho de localização. |
204 | Sem conteúdo | Aparece quando o corpo da resposta é branco. Por exemplo, este código será exibido quando a solicitação DELETE for executada com sucesso |
304 | Não modificado | Use para reduzir o uso de largura de banda se houver solicitações GET condicionais, o corpo da resposta estiver vazio e os cabeçalhos tiverem metadados como local e data |
400 | Pedido ruim | Indica que a entrada do lado do cliente tem dados inválidos fornecidos na solicitação. Por exemplo, pode ter dados ausentes ou parâmetros inadequados |
401 | Não autorizado | Indica que o cliente não está autorizado a acessar (não autenticado) |
403 | Proibido | Indica que o cliente foi clicado para executar o método, por exemplo, os códigos exibidos quando o cliente não possui direitos de administrador, mas deseja realizar uma solicitação DELETE de dados no recurso do servidor. |
404 | Não encontrado | Indica que o método não foi encontrado |
409 | Conflito | Indica que foi encontrado um conflito durante a execução do método solicitado. Por exemplo, esse código é exibido se o cliente tentar adicionar um recurso com , mas o recurso já existir. |
500 | Erro do Servidor Interno | Indica que o servidor capturou uma exceção durante a execução do método |
Software usado para acessar
Cliente
O software Postman pode ser usado como cliente ao acessar a API REST
Servidor
Com o servidor, se você usa frameworks para codificação, certamente haverá um mecanismo para construir uma API para o servidor de acordo com a estrutura do framework, se você não aprendeu, pode abordar algumas das empresas que fornecem APIs populares para praticar cliente comunicação, por exemplo:
- Airtable : um sistema de armazenamento de banco de dados de linha e coluna com recursos semelhantes ao Excel, mas mais desenvolvidos, fornecendo APIs para comunicar mais, editar, excluir
- API Mapbox : Free Map fornece API para poder desenhar mapas online
- Openweather: fornece API para obter clima
- …
O artigo acima fornece conceitos básicos sobre como usar a API REST para interagir entre cliente e servidor, espero que depois de ler você entenda melhor o conceito de arquitetura e também como usar a API REST.