REST API WITH PYTHON PHP NODEJS GO DJANGO LARAVEL LUMEN Examples
1.0.0
O descanso é acrônimo para transferência de estado representacional . A API RESTful é um estilo arquitetônico para uma interface do programa de aplicativos (API) que usa solicitações HTTP para acessar e alterar dados. Esses dados podem ser usados para obter, colocar, publicar e excluir tipos de dados, que se referem à leitura, atualização, criação e exclusão de operações sobre recursos. Para mais detalhes
As principais funções usadas em qualquer arquitetura baseada em descanso são:
Seu aplicativo deve satisfazer certas restrições ou princípios. Vamos entrar em detalhes sobre esses princípios.
Existem seis princípios terrestres, abaixo estão os seis princípios orientadores de descanso:
Estado sem estado: solicitações enviadas de um cliente para o servidor contém todas as informações necessárias necessárias para entendê -las completamente. Pode fazer parte do URI, parâmetros de cordas de consulta, corpo ou até cabeçalhos. O URI é usado para identificar exclusivamente o recurso e o corpo detém o estado do recurso solicitante. Depois que o processamento é feito pelo servidor, uma resposta apropriada é enviada de volta ao cliente através de cabeçalhos, status ou corpo de resposta.
Cliente-servidor: ele possui uma interface uniforme que separa os clientes dos servidores. A separação das preocupações ajuda a melhorar a portabilidade da interface do usuário em várias plataformas, além de melhorar a escalabilidade dos componentes do servidor.
Interface uniforme: Para obter a uniformidade ao longo da aplicação, o REST definiu quatro restrições de interface que são:
Resource identification
Resource Manipulation using representations
Self-descriptive messages
Hypermedia as the engine of application state
Cache: para fornecer um melhor desempenho, os aplicativos geralmente são criados em cache. Isso é feito rotulando a resposta do servidor como cache ou não cache implicitamente ou explicitamente. Se a resposta for definida como em cache, o cache do cliente poderá reutilizar os dados de resposta para respostas equivalentes no futuro. Também ajuda a impedir a reutilização dos dados obsoletos.
Sistema em camadas: a arquitetura do sistema em camadas permite que um aplicativo seja mais estável, limitando o comportamento do componente. Essa arquitetura permite o balanceamento de carga e fornece caches compartilhados para promover a escalabilidade. A arquitetura em camadas também ajuda a melhorar a segurança do aplicativo, pois os componentes em cada camada não podem interagir além da próxima camada imediata em que estão.
Código sob demanda: o código sob demanda é uma restrição opcional e é o mínimo. Ele permite que o código ou applets de um cliente seja baixado e estendido através da interface a ser usada dentro do aplicativo. Em essência, simplifica os clientes criando um aplicativo inteligente que não depende de sua própria estrutura de código.
Agora que você sabe o que é uma API REST e o que você precisa para fornecer um aplicativo eficiente, vamos mergulhar mais fundo e ver o processo de criação da API de REST usando todas as tecnologias e estruturas de tendências.
O REST e o Simple Object Access Protocol (SOAP) oferecem métodos diferentes para invocar um serviço da Web. O REST é um estilo arquitetônico, enquanto o SOAP define uma especificação de protocolo de comunicação padrão para troca de mensagens baseada em XML. Os aplicativos de repouso podem usar sabão.
Os serviços Web RESTful são sem estado. Uma implementação baseada em REST é simples em comparação com o SOAP, mas os usuários devem entender o contexto e o conteúdo que estão sendo transmitidos, pois não há um conjunto padrão de regras para descrever a interface de serviços da Web REST. Os serviços de repouso são úteis para dispositivos de perfil restritos, como móveis, e são fáceis de integrar aos sites existentes.
O SOAP requer menos código de encanamento, o que significa código de infraestrutura de baixo nível que conecta os módulos de código principal do que o design dos serviços de repouso. O idioma da descrição dos Serviços da Web descreve um conjunto comum de regras para definir as mensagens, ligações, operações e localização do serviço. Os serviços da Web SOAP são úteis para processamento e invocação assíncronos.
Estes são alguns pontos que você deve considerar ao desenvolver API REST:
Cargas úteis extremamente grandes de dados de resposta diminuirão a conclusão da solicitação, outras chamadas de serviço e, afetando o desempenho de degradação. Como você sabe, agora que estamos retornando todos os pedidos para o cliente, em vez de apenas seu pedido atual, teremos que lidar com alguma degradação do desempenho.
Podemos usar GZip Compression para reduzir o tamanho da carga útil. Isso diminui o tamanho do download da nossa resposta no aplicativo da web (lado do cliente), além de aumentar a velocidade de upload ou a criação de alguma entidade (pedidos). Podemos usar Deflate compression em uma API da Web. Ou, podemos atualizar o cabeçalho Acep-EncodingRequest para o GZIP .
O cache é um dos métodos mais fáceis para melhorar o desempenho de uma API. Se tivermos solicitações que frequentemente retribuam a mesma resposta, uma versão em cache dessa resposta ajuda a evitar chamadas adicionais de serviço/consultas de banco de dados . Você deseja ter certeza de que, ao usar o cache, para invalidar periodidar os dados no cache, especialmente quando ocorrem novas atualizações de dados.
Digamos que nosso cliente queira fazer um pedido de uma parte automática, e nosso aplicativo chama algumas API de peças de automóveis para buscar o preço da peça. Como a resposta (preço da peça) muda apenas uma vez por semana (às 1:00 da manhã), podemos armazenar em cache a resposta pelo resto do tempo até então. Isso nos salva de fazer uma nova chamada toda vez para retornar o mesmo preço da peça. Caso semelhante Você pode usar o cache para evitar chamadas ou solicitações extras.
Uma rede lenta degradará o desempenho mesmo da API mais robusta. Redes não confiáveis podem causar tempo de inatividade, o que pode fazer com que sua organização viole os SLAs, os termos de serviço e as promessas que você pode ter feito aos seus clientes. É importante investir na infraestrutura de rede adequada, para que possamos manter o nível de desempenho desejado. Isso pode ser conseguido aproveitando e comprando recursos e infraestrutura de nuvem suficientes (example: in AWS, allocate the proper # of EC2 instances, use a Network Load Balancer) . Além disso, se você tiver uma grande quantidade de processos em segundo plano, execute aqueles em threads separados para evitar o bloqueio de solicitações. Você também pode usar espelhos e redes de entrega de conteúdo (CDNs), como o CloudFront para atender às solicitações mais rapidamente em torno de diferentes partes do mundo.
Você pode ter uma situação em que sua API sofre um ataque de DDOs que pode ser malicioso e intencional ou ingresso quando um engenheiro chama a API para executar um loop a partir de algum aplicativo local. Você pode evitar isso medindo transações e monitoring the number of how many transactions occur per IP Address, or per SSO/JWT Token (if the customer/calling app is authorized before calling the API) .
Esse método para limitar a taxa ajuda a reduzir solicitações excessivas que diminuiriam a API, ajuda a lidar com chamadas/execuções acidentais e monitorar proativamente e identificar possíveis atividades maliciosas.
É um equívoco comum entre os engenheiros que as operações de colocação e patch produzem o mesmo resultado. Eles são semelhantes na atualização de recursos, mas cada um executa as atualizações de maneira diferente. Coloque as operações atualize os recursos enviando atualizações para todo o recurso. As operações de patch aplicam atualizações parciais apenas aos recursos que precisam ser atualizados. Resultantes de chamadas no INPATCH que produzem cargas úteis menores e melhoram o desempenho em escala.
Pro-Tip: Even though PATCH calls can limit the request size, you should note that it is not Idempotent.
Meaning, it is possible that a PATCHcan yield different results with a series of multiple calls.
So, you should carefully and deliberately consider your application for using PATCH requests,
and make sure that they are idempotently implemented if needed. If not, use PUT requests.
Esta é talvez uma das dicas mais importantes que você lerá aqui. Se há uma coisa que você deve aprender com este repositório, deve ser isso! Nenhuma negociação sobre este.
Ter toras, monitoramento e alerta ajuda os engenheiros diagnosticar e remediar problemas antes que eles se tornem problemas . Muitas APIs (Express/Node, Java, Go) têm terminais predefinidos para avaliar coisas como:
`/health`
`/metrics`
Se você não tiver o log ativado e existe um problema em potencial, não poderá rastrear a origem ou onde o problema está ocorrendo em uma solicitação específica.
Se você não tiver monitoramento ativado, não saberá de uma perspectiva analítica com que frequência alguns problemas ou erros estão ocorrendo. O que impedirá que você pense em possíveis soluções.
E ... se você não tiver alerta ativado, não saberá se há um problema, até que um cliente (ou pior, clientes) o relate.
A paginação ajuda a criar baldes de conteúdo a partir de várias respostas . Esse tipo de otimização ajuda a melhorar as respostas, preservando os dados que são transferidos/exibidos para um cliente. Você pode padronizar, segmentar e limitar as respostas que ajudam a reduzir a complexidade dos resultados e melhorar a experiência geral do cliente, fornecendo a resposta/resultados apenas para o que um cliente solicitou.
Sabemos que as APIs são incríveis e podem ser extremamente poderosas para proporcionar aos negócios e aos clientes uma ótima experiência, se adequadamente otimizados e aprimorados para o desempenho. Os requisitos de negócios e as expectativas do cliente sempre evoluem com o tempo. E como engenheiros responsáveis, cabe a nós decidir como construir nossas APIs de maneira performática, que pode nos ajudar a alcançar e exceder nossos objetivos.
Essas dicas são apenas a ponta do iceberg e se aplicam a todas as APIs em um ambiente geral. Dependendo da sua API e caso de uso específicos, quais serviços ele interage, com que frequência é chamado, de onde é chamado, etc. Você pode ter que implementar essas dicas de maneiras diferentes.
API REST com Laravel - passaporte
API REST com PHP - OOPS
API REST com Python - Flask
API REST com Python - Django - Restframework
Rest Api com Go - Mux
API REST com GO - Gin
API REST com NodeJS - Express - Basic
REST API com NodeJS - Express- JWT - Sequellze - Avanço
Muito fácil de criar API REST em alguns minutos, você pode escolher qualquer uma das preferências de código de código acima de acordo com o seu idioma e as preferências da estrutura e seguir as instruções para criar a API REST.
Codificação feliz?
LinkedIn: https://www.linkedin.com/in/the-startup-cto/
Médio: https://apige.medium.com/
Twitter: https://twitter.com/htngapi
