Termos que todo técnico de API deve conhecer
O espaço tecnológico está em constante evolução, assim, manter-se atualizado com as terminologias mais recentes é essencial.
Se você está apenas começando em APIs, estes são alguns dos termos mais usados que todo tecnólogo de API deve conhecer.
API Uma Interface de Programação de Aplicativo (API) é um sistema de código interno e terminais associados que permite a conexão e comunicação entre dois sistemas.
APIs podem existir em várias formas. Por exemplo, os computadores utilizam APIs para conectar a comunicação entre diferentes sistemas internos para traduzir solicitações de renderização gráfica para processadores discretos. No contexto da World Wide Web e da Internet, as APIs conectam servidores e sistemas de dados para permitir a recuperação, permutação e alteração.
Call/Request-Chamada/Solicitação
Quando um usuário final interage com uma API para realizar uma tarefa, essa interação é facilitada por uma chamada de API, também chamada de solicitação. Essas ações são feitas em um endpoint que filtra a solicitação ou as chamadas para o aspecto correto da API e seu conjunto de dados associado.
Endepoints
Endpoints são URLs/URIs definidos associados a uma ação ou função específica da API principal. Por exemplo, se uma API meteorológica puder fornecer dados para uma área específica conforme definido por coordenadas, isso provavelmente existiria como um endpoint específico – outras funções também existiriam como seus próprios endpoints discretos.
Os endpoints geralmente são limitados a uma única função, embora variações dessa função também possam existir nesse endpoint aguardando ativação por meio de parâmetros adicionais passados.
Parameters -Parâmetros
Os parâmetros são variáveis na chamada ou solicitação do terminal que permitem que uma permutação seja executada entre a solicitação e a saída. Por exemplo, uma API pode fornecer saída de dados para uma solicitação em três formatos diferentes e, para escolher um formato específico, pode ser necessário fornecer um parâmetro.
Headers – Cabeçalhos
Os cabeçalhos são elementos da solicitação e resposta da API usados para transmitir informações adicionais. Essas informações adicionais podem ser de uma grande variedade, embora o caso de uso de informações mais comum seja passar metadados e contexto para o próprio conteúdo.
External and Internal – Externo e Interno
Uma API externa é criada para uso externo pelo público e é projetada para enfrentar uma ampla base de usuários.
As APIs internas são destinadas ao uso interno por uma organização ou coleção de usuários e não devem ser acessadas por uma base de usuários ou público mais amplo. Há também APIs de parceiros e outros estilos emergentes.
Implementation- Implementação
Uma implementação é a implantação total da base de código e seus dados associados para criar uma solução total para um problema específico.
Os desenvolvedores geralmente se referem à sua solução específica como uma “implementação”. Se duas implementações são quase idênticas com apenas uma pequena alteração entre elas, elas ainda são consideradas duas implementações separadas e distintas.
Client – Cliente
As APIs tendem a ser discutidas no contexto de um relacionamento cliente-servidor. Os clientes são os dispositivos ou sistemas que se comunicam com o servidor e normalmente são a entidade que faz solicitações em nome dos usuários finais.
Clientes comuns incluem computadores pessoais e telefones celulares. Servidor As APIs tendem a ser discutidas no contexto de um relacionamento cliente-servidor.
Os servidores são os sistemas que respondem às solicitações dos clientes, oferecendo a saída de dados transformada e entregue. Os servidores são separados do usuário final e normalmente representam o lado de armazenamento e manipulação de dados do fluxo de solicitação.
Methods HTTP
Métodos HTTP são os métodos de interação padrão codificados pelo padrão HTTP, ou HyperText Transfer Protocol. Esses métodos são comumente usados para interagir com dados utilizando APIs.
Os métodos mais comuns são mostrados abaixo.
- GET é usado para recuperar informações utilizando um URI específico. GET deve apenas recuperar dados e não deve alterar os dados de forma alguma.
- PUT é usado para substituir as representações atuais do recurso por uma nova representação. Em essência, é usado para substituir dados por novos dados.
- DELETE é usado, curiosamente, para excluir as representações atuais de dados. Chaves Chaves de API são sequências de dados específicas usadas para identificar um usuário ou aplicativo e fornecer autenticação.
- As chaves geralmente são usadas para proteger uma API e são amplamente usadas em aplicativos comuns, como OAuth, para controlar o fluxo de informações e funções.
Cache
Um cache de API é a área em um sistema de API que armazena dados que foram solicitados pelos usuários para acesso adicional no futuro.
Os dados armazenados em cache geralmente são muito menos intensivos e muito mais rápidos para servir em comparação com dados não armazenados em cache e, se uma solicitação for feita com frequência para um ponto específico de dados, especialmente se esses dados não forem atualizados com frequência, o armazenamento em cache é uma solução ideal.
JSON
JSON, ou JavaScript Object Notation, é um formato de intercâmbio de dados desenvolvido a partir de um subconjunto de JavaScript. JSON é muito leve, mas ganha isso através da simplicidade, o que significa que muitas vezes é difícil representar estruturas extremamente complexas.
O JSON é independente de linguagem, mas grande parte de sua forma e função é semelhante à família de linguagens C, tornando-o um formato popular ao trabalhar com aplicativos baseados em C. XML XML, ou Extensible Markup Language, é uma linguagem de marcação e um sistema de formato de arquivo para armazenamento e transmissão de dados.
Ele utiliza um sistema de definição de conjunto de regras de codificação nativo para criar um formato que seja legível por humanos e por máquina.
XML é muito verboso, mas o que perde em eficiência ganha em sua capacidade de representar estruturas complexas definidas arbitrariamente pelo usuário.
GraphQL
GraphQL é uma linguagem de consulta que tem sido amplamente adotada como forma de fornecer respostas de formulário personalizadas. Ele permite que os solicitantes definam a estrutura e a forma da saída resultante de sua solicitação, o que permite que uma forma e função específicas sejam entregues de acordo com as necessidades do cliente.
Terminologia de negócios e desenvolvedores Estrutura Frameworks são a coleção de bibliotecas, instruções e APIs que formam um sistema estrutural subjacente a um desenvolvimento ou implementação específica. A estrutura representa uma solução coletiva da qual as APIs podem extrair recursos para atingir um objetivo específico.
Shema
Shema são sistemas de metadados que estruturam os sistemas e dados subjacentes à API. Os esquemas são essenciais para o design da API e normalmente representam um paradigma ou modo específico de entrega e consumo.
Monetization – Monetização
A monetização é o processo de alavancar o valor em uma API para gerar receita. Isso pode ser feito de várias maneiras, incluindo o fornecimento de avaliações gratuitas que resultam em cobranças pelo uso contínuo (freemium), cobranças pela quantidade de utilização (taxa de cobrança) e outros modelos.
A monetização geralmente é um ato de equilíbrio entre fornecer a maior quantidade de utilidade inicial ao usuário final e criar uma fonte de receita potencial para financiar o desenvolvimento e a operação contínuos.
API-as-a-Product – API como um produto
API-as-a-Product – é o termo para descrever um modelo de negócios em que a API é a oferta principal do produto.
Uma API como produto normalmente monetiza um serviço ou funcionalidade de nicho, permitindo que a parte consumidora terceirize uma parte de sua TI de maneira reutilizável. A tendência de API como produto atingiu o pico nos últimos anos, à medida que as empresas começam a perceber o valor das ofertas de API em primeiro lugar.
Production Environment – Ambiente de produção
O ambiente de produção de uma API é o ambiente que reflete o caso de uso real do usuário final. Isso é diferente de um ambiente de teste ou ambiente simulado, pois o aplicativo é executado em tempo real em condições do mundo real. Um ambiente de produção é com o qual o consumidor da API irá interagir e nem sempre pode corresponder à forma como o serviço é documentado – uma realidade conhecida pela Lei de Hyrum.
SDK
Um Software Development Kit (SDK) é uma caixa de ferramentas de práticas, métodos, amostras de código, documentação, diretrizes de implementação e instruções de construção para criar aplicativos em uma plataforma ou sistema específico. Os SDKs permitem que os desenvolvedores desenvolvam dentro de um conjunto restrito de diretrizes e geralmente atendem a uma linguagem de programação específica. Como tal, os SDKs variam de plataforma para plataforma.
Lifecycle – Ciclo da vida
O ciclo de vida de uma API é o tempo desde sua criação até sua obsolescência final, ou “pôr do sol”. Esse período pode incluir atualizações de longo prazo após seus dados de obsolescência, e o suporte de longo prazo pode às vezes ser considerado separado do ciclo de vida ativo inicial (nesses casos, variações em termos como “suporte de longo prazo” ou “suporte de fim de ciclo de vida ” são comuns). SDLC SDLC, ou Software Development Lifecycle, é o processo geral de idealização, planejamento, desenvolvimento, teste e implantação de um desenvolvimento de software específico.
O SDLC é um processo específico, mas pode ser implantado por meio de vários modelos diferentes, incluindo cascata, iterativo, ágil e outros. O objetivo final do SDLC é fornecer a solução da mais alta qualidade com o menor custo em termos de dinheiro e tempo.
Arquiteturas, Protocolos e Paradigmas
Rest -Representation State Transfer
REST é um paradigma arquitetural para desenvolvimento e design de API que foi criado por Roy Fielding como parte de sua dissertação chamada “Estilos de Arquitetura e o Design de Arquiteturas de Software Baseadas em Rede”.
Há uma variedade de considerações que devem ser atendidas para que uma API seja considerada RESTful, mas de modo geral, uma API RESTful será stateless, o que significa que o servidor não armazenará dados referentes à sessão do cliente no lado do servidor.
SOAP- Simple Object Access Protocol
SOAP é um protocolo projetado para trocar dados entre aplicativos. O SOAP usa XML como formato para seus elementos de envelope, cabeçalho e corpo e Web Services Description Language (WSDL) como formato para os esquemas de mensagem. O SOAP é altamente estruturado e, como o REST, não possui estado.
Ao contrário do REST, no entanto, o SOAP pode ser feito com estado, tornando-o mais apropriado para casos de uso nos quais o estado deve ser preservado.
Monolith – Monólito
A maneira tradicional de desenvolver sistemas de software era criar tudo como uma entidade única, empacotando funções com conjuntos de dados em uma estrutura monolítica.
Embora isso ainda seja padrão em alguns casos de uso, o desenvolvimento monolítico normalmente significa que pequenas alterações devem ter efeito em toda a base de código, aumentando os custos de desenvolvimento tanto monetariamente quanto em termos de tempo.
O desenvolvimento monolítico ainda tem seu lugar, especialmente quando o software deve ser altamente seguro ou desenvolvido para casos de uso interno.
Microsserviços
O design baseado em microsserviços, também conhecido como arquitetura de microsserviços, tornou-se um modelo de desenvolvimento quase onipresente no espaço da API. Em contraste com o monolito, os microsserviços dividem cada grupo de funções e seus conjuntos de dados associados em seus próprios aplicativos independentes e fracamente acoplados.
Uma solução centrada em microsserviços pode ter as funções de gerenciamento de usuários, facilitação de solicitações, banco de dados e armazenamento e transformação, todas separadas em diferentes aplicativos.
Isso torna o desenvolvimento um pouco mais complexo, mas permite que sejam feitas alterações em um sistema enquanto outros componentes permanecem inalterados. Empurrar “Push” é um paradigma de API no qual o conteúdo é “enviado” para o usuário sem uma solicitação direta do usuário final.
Isso é usado com mais frequência no contexto de assinatura, em que um usuário solicita atualizações em uma data posterior e a API “envia” para o usuário inscrito quando algo sobre os dados é alterado ou atualizado.
Puxar “Pull” é um paradigma de API no qual o conteúdo é “puxado” conforme a solicitação de uma solicitação direta do usuário. Essa é a experiência mais tradicional para o usuário final que envia chamadas de API pela Internet. Quando os usuários discutem o uso de endpoints para fazer chamadas, geralmente estão se referindo a esse paradigma.
Webhook
Webhooks são APIs orientadas por trás de um paradigma de design Push. Os webhooks enviam automaticamente dados em tempo real para outros aplicativos e APIs utilizando várias soluções técnicas, permitindo a disponibilidade imediata de dados para uma variedade de funções transformadoras.
FONTE: NordicAPIs
IMAGEM: Imagem de starline no Freepik
