O intercâmbio de dados entre múltiplas plataformas é mais crucial do que nunca na era das integrações. Considerar uma loja online sem integrações. O seu website teria de desenvolver sistemas de gestão de contas de utilizador, subscrições de correio electrónico, processamento de pagamentos, expedição, e outras tarefas para além da gestão de listagens de produtos. Seria mais eficaz subcontratar estas tarefas a outros fornecedores, uma vez que esta não é uma opção escalável.
Asinterfaces de programação de aplicações, ou APIs da web, são o que os programas de software utilizam para comunicar uns com os outros. As APIs oferecem um protocolo consistente para o intercâmbio de dados entre dois programas. Com a ajuda de APIs da web, a sua loja online pode comunicar com software de entrega, aplicações clientes, aplicações de pagamento, e quaisquer outras ligações necessárias.
Há várias maneiras de criar uma API; no entanto, se quiser adicionar ligações de software aos seus serviços, há uma técnica única com a qual deve estar familiarizado: Serviços Web REST APIs. Neste artigo, iremos discutir exemplos de API REST, o que é a API REST, como funcionam as APIs REST, para que são utilizadas as APIs REST, história, seus elementos, e muito mais.
O que é exactamente uma API REST?
A transferência de estado representativa ou serviços Web REST APIs são a prática mais padronizada para ligar componentes em estruturas de microserviços, porque oferecem uma forma versátil e portátil de incorporar aplicações. REST é um desenho popular de API que empregamos para interagir com as partes interessadas internas e externas de uma forma padronizada e previsível.
Os utilizadores de aplicações web empregam frequentemente serviços web REST APIs para comunicar uns com os outros. Por exemplo, a aquisição e revisão de detalhes de conta num programa de comunicação social. Os navegadores REST APIs podem ser vistos como a sintaxe da web. Os clientes online utilizam as APIs da web para fornecer e gerir o acesso a operações digitais à medida que a utilização da nuvem aumenta.
A concepção de APIs web que permitem aos clientes ligarem-se, administrarem e envolverem-se dinamicamente com serviços web digitais num contexto disperso, é uma decisão sensata. Websites como Google, eBay, Facebook, Amazon, e Twitter empregam serviços web RESTful. As aplicações clientes podem agora utilizar REST para aceder a estes serviços web.
A tecnologia REST é favorecida em relação a outras tecnologias relacionadas. Isto porque os serviços Web REST consomem menos largura de banda, o que os torna ideais para a actividade online em efficient. Os serviços web RESTful também podem ser desenvolvidos utilizando linguagens de programação como JavaScript ou Python.
Como funcionam os APIs REST?
Para saber como funcionam as APIs REST, temos de definir alguns termos chave:
Cliente
Um utilizador de API é referido como um cliente. O cliente envia consultas para as APIs da web para obter dados ou aplicar modificações ao programa. O seu navegador da Internet é um cliente; comunica com várias APIs da web para obter o conteúdo da página. O seu computador recebe a informação necessária, que é depois mostrada no ecrã.
Os métodos HTTP mais populares são os seguintes:
- Utilize o pedido GET para devolver os dados solicitados ou os recursos solicitados.
- Utilize o pedido POST para fazer um novo recurso
- Utilizar a instrução PUT para fazer alterações ou continuar a actualizar um recurso existente
- Use o comando DELETE para se livrar de um recurso.
Por exemplo, um pedido HTTP à API do Youtube poderia ser um recurso de pedido GET para um determinado vídeo ou postagem ou um pedido POST para publicar uma nova foto. Pode usar o método de pedido POST para publicar novos posts. De forma correspondente, uma plataforma de serviços web do cliente que se integra com uma implementação de auto-atendimento pode empregar a instrução PUT para actualizar ou eliminar um olá personalizado.
Obter Pedido
- O histórico do navegador inclui os pedidos de GET.
- Os pedidos de Bookmarking GET são possíveis.
- Nunca utilizar pedidos de GET enquanto se trabalha com material crítico.
- Há limitações de comprimento nos pedidos de GET.
- Apenas consultas de dados são feitas através de pedidos GET.
O método POST
O pedido POST é um método de correio para enviar informação a um servidor para adicionar ou actualizar recursos. O corpo do pedido de um pedido HTTP contém os dados que são publicados para o lado do servidor:
- O método de pedido POST nunca entra numa cache.
- Os pedidos POST não são armazenados no histórico do browser.
- Os pedidos POST não são marcáveis por bookmark
Corpo de resposta
O corpo de resposta é um dos elementos importantes da API RESTful. Os dados solicitados são incluídos no corpo de resposta. O corpo de resposta pode incluir dados relativos às portas lógicas de saída e de saída.
Recurso
Quaisquer dados que as APIs da web possam dar ao utilizador são um recurso. Por exemplo, um indivíduo, página, imagem, ou comentário podem ser todos considerados recursos na API do Facebook. O identificador do recurso é um termo especial dado a cada recurso.
Servidor Web
O programa que aceita o organismo de pedido do cliente utiliza um servidor web, que aloja os recursos que o consumidor pede. O servidor pode comunicar com os clientes através de um API sem oferecer aos clientes acesso imediato às informações mantidas nas suas bases de dados. Quando um utilizador acede aos serviços Web RESTful para submeter um organismo de pedido, o servidor envia uma descrição normalizada do estado do recurso para o navegador.
Isto significa que o servidor, de alguma forma, não submete o recurso exacto ao cliente, mas reflecte o seu estado, ou seja, a situação do recurso a uma hora específica. Para facilitar a compreensão, as respostas são devolvidas num formato leve.
JSON (JavaScript Object Notation) é amplamente utilizado, uma vez que é legível tanto por pessoas como por máquinas e destaca-se por ajudar a promover a acessibilidade da web. O JSON é utilizado principalmente para o envio de pedidos em aplicações web e aplicações de clientes. É uma forma compatível com uma variedade de codificações. Os formatos de dados API que não o JSON envolvem XML, YAML, CSV, HTML, e texto simples. Os utilizadores de APIs podem seleccionar qualquer formato de dados que desejem, utilizando tipos de suportes personalizados.
Histórico de APIs REST
Muitos programadores tiveram de trabalhar com SOAP antes de REST para incorporar APIs. A construção, utilização e depuração de SOAP eram tarefas notoriamente difíceis. Felizmente, REST foi desenvolvido por uma equipa de programadores sob a direcção de Roy Fielding, alterando para sempre o ambiente API.
Aqui está uma cronologia do desenvolvimento das APIs REST ao longo do tempo:
Antes de REST
Os programadores escreveram manualmente um ficheiro XML contendo uma Chamada de Procedimento Remoto (RPC) dentro do conteúdo para ligar APIs web usando SOAP. Depois disso, os programadores colocariam o seu pacote SOAP no ponto final especificado.
No ano 2000
Uma equipa de programadores liderada por Roy Fielding optou por desenvolver uma estrutura que permitisse a qualquer servidor comunicar com qualquer outro servidor. Ele estabeleceu as restrições para REST APIs. Como estas directrizes são universais, o desenvolvimento de software é mais fácil.
No ano de 2002
eBay desenvolveu o seu RESTful API em 2002, abrindo o seu mercado a qualquer website que pudesse beneficiar do mesmo. Devido a isto, outro titã do comércio electrónico, a Amazon, interessou-se por ela e, em 2002, lançou o seu RESTful API.
No ano de 2004-2006
Os serviços web RESTful do Flickr foram lançados em 2004, permitindo aos escritores adicionar rapidamente fotografias aos seus sítios web e aos postos de comunicação social. Quando o Twitter e o Facebook notaram um número significativo de programadores a digitalizar os websites e a fazer "Frankenstein" APIs, ambos expuseram as suas APIs cerca de dois anos mais tarde.
No ano de 2006-Presente
Os serviços web RESTful são agora amplamente aceites pelos programadores, que utilizam estes serviços web RESTful para melhorar o desempenho das suas aplicações e sítios. O AppMaster facilita a cooperação e facilita a construção de APIs, o que lhe permite fazê-lo mais rapidamente.
Para que são utilizados os APIs REST?
Um dos principais benefícios dos serviços Web RESTful é que oferece uma grande flexibilidade, permitindo-lhe utilizar esta API RESTful de forma mais eficaz. Abaixo estão alguns exemplos de API REST APIs para as quais são utilizadas.
Aplicações baseadas na nuvem
Devido à apatridia das suas chamadas, os APIs REST são vantajosos em aplicações na nuvem. Os módulos apátridas podem facilmente reinstalar-se e crescer para satisfazer os requisitos de capacidade se algo correr mal. Um programa de software que combina componentes locais e baseados na Internet é uma aplicação de nuvem. Este paradigma utiliza servidores distantes acedidos por um navegador web e serviços web contínuos da Internet para executar instruções.
A localização tradicional de anfitriões de aplicações de nuvem é um sistema informático distante executado por um operador de rede de computação em nuvem de terceiros. Correio, partilha e armazenamento de documentos, entrada de encomendas, controlo de inventário, Microsoft Word, gestão de relações com clientes(CRM), recolha de informação, e finanças e contabilidade são exemplos de trabalhos realizados com aplicações baseadas na nuvem.
As interfaces de programação de aplicações REST(APIs) podem ser utilizadas para ligar fontes externas de informação e recursos de armazenamento. Os programadores podem tornar as aplicações na nuvem mais pequenas utilizando as APIs REST para transferir dados para outros programas para manipulação ou análise de cálculos e devolução dos resultados ao programa de software. As APIs testadas reforçam a uniformidade activa, o que pode acelerar a produção e produzir resultados reais.
Um exemplo de uma aplicação em nuvem é o Google Docs ou Office 365. Tudo o que necessita para o Google Docs ou Office 365 é um computador que possa executar motores de busca e serviços web da Internet. As redes informáticas fornecem a interface do utilizador e as operações, incluindo o armazenamento de informação. Numerosas aplicações de nuvem distintas podem ser alojadas pela sua empresa utilizando hospedeiros de aplicações de nuvem.
Serviços na nuvem
Uma vez que seria necessário gerir a forma como o URL é processado para se ligar a um recurso através de uma API, as APIs REST também são úteis para serviços web na nuvem. A arquitectura de serviços web REST tornar-se-á provavelmente agora padrão no futuro devido às aplicações na nuvem. Os programadores utilizam serviços web RESTful para se ligarem a serviços em nuvem utilizando a Internet. Um programador cria um código que utiliza a API do fornecedor de Internet, dá as entradas e variáveis necessárias, e depois verifica a resposta para garantir que a acção funciona como esperado.
Os utilizadores finais podem aceder a aplicações clientes ou serviços web oferecidos por serviços web na nuvem, tais como infra-estruturas computacionais, sistemas de armazenamento, ou sistemas de seguimento, utilizando um serviço de nuvem como os serviços web RESTful. As APIs descrevem as capacidades e operações de uma aplicação e as especificidades necessárias para a sua realização. Para manter a privacidade e segurança do cliente, as APIs dependem frequentemente de mecanismos de interoperabilidade e permissão REST ou Simple Object Access Protocol (SOAP), como o OAuth 2.0.
Uma variedade de serviços web são referidos como "serviços em nuvem" e são disponibilizados a empresas e consumidores online mediante pedido. Estes serviços web são criados para oferecer acesso rápido e barato a ferramentas e aplicações sem a necessidade de hardware ou infra-estrutura. A maioria do pessoal utiliza os serviços web na nuvem para tudo, desde o correio electrónico à colaboração de documentos.
Utilização da web
Estas APIs web podem ser obtidas a partir de um projecto web do utilizador, uma aplicação iPhone, um dispositivo IoT, ou um Windows Mobile uma vez que o REST não depende da funcionalidade do lado do cliente. Pode criar a arquitectura para o seu negócio sem estar limitado a uma estrutura específica do lado do cliente.
Um exemplo de API REST
Vamos discutir um exemplo do REST API. Clique no link abaixo para pedir à Open Trivia Database um inquérito de inteligência arbitrária: Tais serviços RESTful web foram utilizados para fornecer uma API web pública. O seu computador exibirá uma pergunta solitária e as suas respostas em formato JSON.
Usando qualquer navegador HTTP, como url, poderá emitir a seguinte pergunta e receber uma resposta no corpo da resposta: https://opentdb.com/api.php?amount=1&category=18
O Corpo de Resposta do ficheiro XML do serviço web conterá toda a informação do empregado.
Todos os dialectos de programação e ferramentas de desenvolvimento amplamente utilizados têm bibliotecas clientes HTTP, tais como recuperar em JavaScript, Node.js, e Deno e obter conteúdo() em PHP. Uma resposta JSON pode ser lida e utilizada uma vez que é legível na máquina antes de ser exibida em HTML ou outro estilo.
As APIs de Descanso e REST
Ao longo do tempo, desenvolveram-se muitos métodos de transmissão de dados. Pode ter-se deparado com escolhas como CORBA, SOAP, ou XML-RPC. A maioria desenvolveu directrizes de mensagens rigorosas. Roy Fielding delineou pela primeira vez REST em 2000, o que é muito mais simples do que os outros.
É uma colecção de sugestões e limitações para serviços Web RESTful em vez de uma norma. Estas consistem nas seguintes restrições arquitectónicas:
Partição Cliente-Servidor
Os clientes e servidores web só podem comunicar numa direcção sob a arquitectura REST: o cliente solicita o controlador do domínio, e o controlador ou servidor responde ao pedido. Os servidores Web não podem apresentar pedidos, e os clientes não podem reagir; o consumidor inicia todas as ligações.
Os serviços Web REST mantêm os clientes e os servidores isolados, facilitando a interacção entre eles. Os computadores dos clientes podem desenvolver-se sem receio de causar impacto noutro alojamento, e os materiais do servidor podem ser alterados sem causar impacto involuntário aos clientes.
Interface uniforme
De acordo com esta estratégia, todas as consultas e reacções devem aderir a um procedimento padrão de proweb ou estilo das suas mensagens. As aplicações e os servidores são desenvolvidos em várias linguagens de programação que funcionam mal uns com os outros com um mediador. Uma interface uniforme é um dialecto que qualquer cliente pode utilizar para interagir com qualquer API REST.
A tradução de pedidos e reacções entre aplicações com interacção normalizada só seria possível. Diferenças menores iriam misturar e perder informação, e as soluções terão de actualizar os seus procedimentos de pedido quando os APIs da web modificarem os seus. Uma interface consistente elimina esta perspectiva.
ACESSO A https://www.googleapis.com/youtube/v3/channels?part=contentDetails
Como todas as aplicações Cliente REST, esta proposta inclui duas peças de dados. A técnica HTTP é GET. Isto descreve a acção que o cliente deseja tomar sobre os recursos. Um utilizador pode fazer quatro métodos HTTP básicos:
HTTP, ou Hyper-Text Transfer Protocol, é a linguagem universal para a maioria das APIs REST. O HTTP não foi concebido com o REST em mente. Além disso, o REST aceitou esta transmissão de dados como critério para as aplicações com reconhecimento REST. Para utilizar HTTP com APIs REST, o cliente submete um pedido num formato que pode estar familiarizado com o mesmo. Um pedido de sinal de vídeo para a API do YouTube, por exemplo, tem este aspecto:
- Utilize o comando GET para obter um recurso.
- Utilize o comando POST para fazer um novo recurso
- Utilize a instrução PUT para fazer alterações ou continuar a actualizar um recurso existente
- Utilize o pedido DELETE para se livrar de um recurso.
Os métodos HTTP especificam a acção que se pretende tomar relativamente a um recurso específico. Os métodos HTTP são também conhecidos como verbos HTTB.
O URL é HTTP
O identificador uniforme do recurso, ou URI, que identifica o recurso pretendido, está contido no URL. O URL é também um ponto final neste cenário, uma vez que é onde a API RESTful entra em contacto com o utilizador do serviço.
Cadeia de consulta: O URL inclui uma cadeia de consulta. A cadeia de consulta é utilizada para definir os parâmetros, aos quais são dados valores.
Depois de receber e verificar a alegação, o servidor web reverte os dados sobre o recurso visado. Tipicamente, os dados são devolvidos numa estrutura conhecida como JSON (JavaScript Object Notation). O JSON apresenta todos os componentes de um recurso num formato portátil que os humanos podem ler facilmente.
Princípios da interface uniforme
A interface uniforme deve seguir os seguintes parâmetros:
HATEOAS: Hipermédia como o motor do estado da aplicação
A Hypermedia é o motor por detrás dos serviços web RESTful. Isto indica que a hipermédia é tudo o que o cliente quer compreender para reconhecer a resposta do fornecedor.
- Apenas o primeiro URI da aplicação do cliente deve ser fornecido ao cliente. A aplicação do cliente deve conduzir continuamente todos os outros materiais e actividades utilizando hiperligações.
- Os serviços web RESTful não requerem a linguagem de consulta de entrada (IDL), que difere de outras APIs
Um tipo de mídia é um nome para o formato de dados de uma representação. O tipo de meio identifica uma definição que delineia como uma representação deve ser tratada. Uma API web que utiliza REST parece ser um hipertexto. Cada item de dados que pode ser endereçado tem uma localização, quer directamente (por exemplo, através de ligação e propriedades de identidade) ou implicitamente (por exemplo, derivado da estrutura de descrição do tipo de meio de comunicação).
Mensagens auto-descritivas
Cada comunicação entre o lado cliente e o lado servidor deve fornecer dados suficientes para executar a comunicação. Consequentemente, o pedido do lado cliente para o lado servidor precisa de especificar o recurso a que está a tentar aceder juntamente com os seus objectivos específicos.
Além disso, as representações de recursos devem ser auto-descritivas; o utilizador não tem de estar consciente se um recurso é uma pessoa ou uma peça de equipamento. Em vez disso, deve responder de acordo com o tipo de suporte ligado à ajuda.
Por conseguinte, indiscutivelmente, desenvolveremos muitos tipos de meios únicos, muitas vezes um tipo de meio por recurso. Cada forma de meios de comunicação especifica um paradigma de produção padrão. Por exemplo, o HTML define como o hipertexto é mostrado e como o navegador lida com cada componente.Identificar os recursos
Os recursos referidos nas comunicações posteriores entre o cliente e o servidor têm de ser reconhecíveis utilizando representações. A adesão ao sistema de Identificador Uniforme de Recursos (URI) permite isto. Por outras palavras, a comunicação do servidor para o cliente pode incluir uma versão HTML do documento e alguma informação em vez do ficheiro real do armazenamento do servidor.
O consumidor pode compreender facilmente a versão HTML porque segue o padrão URI. O cliente deve modificar os recursos, dando ao servidor uma descrição de como o recurso deve, em última análise, aparecer. Isto permitiria ao utilizador construir, recuperar, modificar, e remover recursos. Se o cliente tiver a autorização necessária para alterar os dados, o servidor deve preencher a consulta.
Start FreeTry AppMaster no-code today!Platform can build any web, mobile or backend application 10x faster and 3x cheaper
Apóstrofe
Com uma API RESTful, todos os pedidos de clientes devem ser transitórios. Como resultado, cada órgão de consulta e resposta inclui todos os dados necessários para celebrar o contrato, tornando cada ligação autónoma. O servidor não acompanha os pedidos HTTP anteriores; trata cada um dos pedidos feitos pelo cliente como uma consulta completamente nova.
Uma vez que o servidor não tem de executar quaisquer tarefas extra para obter dados históricos, os transportes sem estado minimizam significativamente a quantidade de armazenamento necessária para o servidor e aumentam a probabilidade de que uma resposta seja aceitável. Isto garante a escalabilidade destas interacções: os programadores não têm de se preocupar em utilizar muito mais armazenamento ou tributar o servidor quando o seu software se expande e faz pedidos HTTP.
Em camadas
Até agora, temos definido as consultas API da web como uma simples troca cliente-servidor, embora isto esteja a simplificar um pouco demais. Entre estas duas organizações, existem frequentemente mais servidores. Estas plataformas, ou camadas, existem para gerir e dispersar o tráfego, adicionar protecção, e executar várias outras tarefas cruciais.
De acordo com este conceito, as mensagens enviadas entre um utilizador e um servidor alvo devem ser estruturadas e tratadas de forma semelhante, independentemente das camadas que existem no meio. As camadas extra devem ser adequadas às interacções com os clientes. Os programadores que aderem a esta regra podem alterar os sistemas do servidor sem afectar o processo fundamental de resposta aos pedidos.
Cacheable
O cache ocorre quando um cliente navega num website quando o conteúdo é guardado na máquina do cliente. O material em cache é rapidamente carregado a partir da memória interna em vez de ser novamente descarregado do servidor quando um utilizador visita esse sítio mais tarde. A maioria dos sítios grandes utiliza o cache para reduzir a carga de páginas enquanto conserva o espaço do servidor e a largura de banda.
O caching de dados é considerado quando se desenvolvem APIs REST. A resposta que um servidor dá a um cliente deve indicar se e em que medida o recurso dado pode ser armazenado.
Em Código de Procura
O último princípio REST é desnecessário. Se solicitado, a resposta de uma API pode incluir o código de software a utilizar pelos clientes. Devido a isto, o cliente pode executar a aplicação ou programa do cliente no seu backend.
Uma API é considerada uma API RESTful se obedecer a este conjunto de directrizes. Estas directrizes, contudo, dão aos programadores muita liberdade para modificar as características da sua API RESTful. As API REST diferem do Simple Object Access Protocol, outra técnica popular de API da web, na medida em que são mais flexíveis (SOAP).
Consenso do ponto final
Ter em conta estes pontos finais:
- /usuário/123
- /usuário/id/123\s
- /user/123\s/user/id/123\s
- /user/?id=123
Todos são métodos legítimos para que o cliente 123 recupere dados. Quando existem procedimentos mais complicados, o número de possibilidades aumenta. Por exemplo, em ordem inversa, a partir da entrada 51, exibem 10 pessoas com apelidos que começam por "A" e funcionam para a empresa.
No final, não importa como se estruturam os URLs; a uniformidade em toda a sua API RESTful é importante. Em grandes sistemas de software com muitos programadores, isso não pode ser fácil. As modificações RESTful API são inevitáveis, mas os URLs de pontos finais nunca devem ser rejeitados porque isso fará com que as aplicações que dependem deles deixem de funcionar.
Versão REST API
A elaboração de APIs de versões é uma prática comum para prevenir incompatibilidades. A título de ilustração, /2.0/user/123 substitui /user/123. O antigo e o novo parâmetros podem ambos continuar a funcionar. Consequentemente, isto força a necessidade de manter as APIs importantes do passado. As versões anteriores podem acabar por ser reformadas, mas o procedimento tem de ser cuidadosamente pensado.
Autenticação da API REST
Qualquer dispositivo pode descarregar um quip sem autorização utilizando a API de consulta. Os APIs que lêem informação privada ou permitem a edição e remoção de consultas, não suportam isto. Os programas do lado do cliente dentro do mesmo domínio que os serviços web RESTful são enviados e recebem cookies da mesma forma que os pedidos HTTP. (Por favor note que a opção de reinício de privilégios deve ser especificada em sítios anteriores para Fetch(). Uma consulta API pode ser verificada para confirmar que um utilizador está registado e tem as permissões necessárias.
Autenticação básica HTTP: Os programas de terceiros devem utilizar diferentes soluções de aprovação. Alguns métodos populares de autenticação são a verificação primária para:
- HTTP. Um nome de utilizador codificado com base64: a cadeia de palavras-passe é dada no campo de consulta como parte de um cabeçalho de aprovação HTTP.
- Chaves API: Ao fornecer uma chave RESTful API que pode ter permissões especiais ou ser limitada a um único site, uma API é disponibilizada a aplicações de terceiros. Cada mensagem contém a chave quer na cadeia de consulta, quer no cabeçalho HTTP. (A cadeia de consulta é um componente do URL).
- OAuth: Antes de fazer quaisquer pedidos, um ID de cliente e talvez um segredo de cliente são enviados para um servidor OAuth para obter uma credencial. Até à sua expiração, a identidade do OAuth é então transmitida juntamente com cada pedido de API.
- Tokens da Internet em JSON (JWT): O cabeçalho da consulta e o cabeçalho da resposta transmitem com segurança as credenciais de utilizador assinadas digitalmente. Os JWT permitem que o servidor encripte privilégios de acesso, eliminando a necessidade de consultar uma base de dados ou utilizar outro mecanismo de autenticação.
O cenário de utilização afectará a forma como uma API é autenticada:
- Por vezes, um programa de terceiros é tratado como qualquer outro cliente registado com os mesmos privilégios e direitos. Por exemplo, uma API de mapa pode fornecer a um programa requerente instruções entre dois pontos. Deve verificar que o programa é um utilizador legítimo, mas não tem de verificar as credenciais do cliente.
- Em outras situações, o programa de terceiros pede informações pessoais a um utilizador específico, tais como conteúdo de correio. As API REST devem reconhecer o cliente e as suas permissões, mas não precisam de se preocupar com o programa de chamadas.
Segurança da API REST
Os serviços RESTful web acrescentam uma forma adicional de interagir com o seu software e influenciá-lo. Mesmo que o seu anfitrião não seja um objectivo elevado de hacking, um utilizador mal-comportado poderia submeter centenas de pedidos por segundo e colapsá-lo. Este artigo não cobre a segurança, mas os melhores procedimentos padrão envolvem:
Faça uso de HTTPS
Empregar um forte mecanismo de autenticação
CORS pode ser utilizado para restringir as chamadas dos clientes a áreas específicas.
Fornecer as necessidades de capacidades - ou seja, não
Gerar escolhas DELETE que não são necessárias; verificar todas as URLs de Endpoint e informação corporal.
Bloquear ligações de sectores não identificados ou endereços IP, não sujeitando os vouchers API no JavaScript do lado do cliente.
Pacotes anormalmente grandes são bloqueados.
Pense na restrição de tarifas, onde os pedidos do mesmo endereço IP ou credencial API são restritos a N consultas por minuto.
Resposta com o código de estado HTTP adequado, consultas de registo de cabeçalho de cache, e investigação mal sucedida
Pedidos múltiplos e dados desnecessários
A implantação de serviços web RESTful tem limitações. É possível que uma resposta tenha mais informações do que as solicitadas ou que sejam necessários vários pedidos para obter todas as informações. Pense nos serviços Web RESTful que dão aos utilizadores acesso à informação do criador e do livro; o cliente poderia:
- Pedir as primeiras 10 informações sobre os livros, listadas por ordem de compra (primeiro o mais vendido). Na resposta está incluída uma colecção de livros, juntamente com a identificação de cada escritor.
Para obter a informação de cada escritor, construir até 10 /author/id queries.
N As consultas API devem ser geradas para cada resposta à consulta pai, caracterizada como o "problema N+1".
Se esta for uma situação de utilização frequente, os serviços RESTful web podem ser modificados para incluir toda a informação do autor para cada livro que produziu, incluindo nome, género, nacionalidade, biografia, e assim por diante. Ainda mais informação sobre os seus livros anteriores pode ser fornecida, embora isso aumente significativamente a carga de resposta. O API pode ser alterado para tornar a informação do escritor opcional. Detalhes do autor=full para evitar respostas desnecessariamente grandes. O número absoluto de opções que os desenhadores de API devem apoiar pode ser esmagador.
Envolvimento
Compreende agora completamente as APIs REST, como funcionam as APIs REST, exemplos de API REST, para que são utilizadas as APIs REST, restrições arquitectónicas, e outros tópicos abordados neste tutorial. Os programadores podem achar difícil e intimidante aprender sobre as APIs, mas a plataforma sem código AppMaster criou uma nova biblioteca de APIs REST acessível onde poderá aprofundar o seu conhecimento sobre uma gama de APIs REST para apoiar o seu desenvolvimento profissional futuro.
Na AppMaster, tentamos aumentar a acessibilidade e a usabilidade das APIs. Queremos que conheça, experimente e perceba os benefícios da utilização de software API na sua carreira e vida pessoal. Para o ajudar a conceber melhores APIs da web mais rapidamente, a AppMaster melhora a colaboração e automatiza cada fase do ciclo de vida da API. Continue a criar, avançar, e ampliar a sua compreensão das APIs REST.
