Artigo original: What is an API? In English, please.

Antes de aprender desenvolvimento de software, API parecia um tipo de cerveja para mim.

Hoje, eu uso o termo com tanta frequência que já tentei, de fato, pedir uma API em um bar.

A resposta do garçom foi um 404: recurso não encontrado.

Encontro muita gente, trabalhando em tecnologia ou não, que tem uma ideia meio vaga ou imprecisa sobre o que significa esse termo bastante comum.

Tecnicamente, API é a sigla para Application Programming Interface, ou Interface de Programação de Aplicações. Em algum momento, a maioria das grandes empresas criou APIs para seus clientes ou para uso interno.

Mas como explicar o que é uma API em bom português? Existe algum significado mais amplo que aquele utilizado em desenvolvimento e nos negócios? Primeiro, vamos dar um passo para trás e ver como funciona a própria web.

A web e os servidores remotos

Quando penso na web, eu imagino uma grande rede de servidores conectados.

Cada página na internet é armazenada em algum lugar em um servidor remoto. Um servidor remoto não é algo tão místico, na verdade — é só parte de um computador localizado em outro lugar (remotamente) que é otimizado para processar solicitações.

Para você ter uma ideia, é possível criar um servidor em seu laptop que é capaz de servir um site da web inteiro (de fato, um servidor local é o que os engenheiros usam para desenvolver sites da web antes de lançá-los para o público).

Quando você digita www.facebook.com no seu navegador, uma solicitação vai para o servidor remoto do Facebook. Quando seu navegador recebe a resposta, ele interpreta o código e exibe a página.

Para o navegador, também conhecido como client, o servidor do Facebook é uma API. Isso significa que toda a vez que você visita uma página na web, está interagindo com a API de algum servidor remoto.

Uma API não é a mesma coisa que um servidor remoto — em vez disso, ela é a parte do servidor que recebe solicitações e envia respostas.

APIs como uma maneira de servir os clientes

Você provavelmente já ouviu falar de empresas que fornecem pacotes de APIs como produtos. Por exemplo, a Weather Underground vende acesso à sua API de dados sobre o clima.

Cenário de exemplo: o site da web de sua pequena empresa tem um formulário usado para agendar reuniões com clientes. Você quer dar aos clientes a capacidade de criar um evento no calendário do Google automaticamente com os detalhes para aquela reunião.

Uso da API: a ideia é fazer com que o servidor de seu site da web fale diretamente com o servidor do Google por meio de uma solicitação para criar um evento com os detalhes fornecidos. Seu servidor, então, receberá uma resposta do Google, a processará e enviará as informações relevantes para o navegador, como uma mensagem de confirmação para o usuário.

Como alternativa, seu navegador pode enviar com frequência uma solicitação de API diretamente para o servidor do Google, desconsiderando o seu servidor.

Qual é a diferença dessa API do calendário do Google para a API de qualquer outro servidor remoto existente?

Em termos técnicos, a diferença é o formato da solicitação e da resposta.

Para renderizar toda uma página da web, seu navegador espera uma resposta em HTML, que contém o código de apresentação, enquanto a chamada da API do calendário do Google apenas retorna dados — normalmente, em um formato como o JSON.

Se o servidor de seu site da web estiver fazendo uma solicitação de API, ele passa a ser o client (semelhante ao fato de o navegador ser o client quando você usa o navegador para ir para um site da web).

Do ponto de vista de seus usuários, as APIs permitem que eles completem a ação sem sair de seu site da web.

A maioria dos sites da web modernos consome pelo menos algumas APIs de terceiros.

Muitos problemas já têm uma solução de terceiros, seja na forma de uma biblioteca, seja na de um serviço. Geralmente, é mais fácil e mais confiável usar uma solução existente.

Não é incomum para equipes de desenvolvimento dividir suas aplicações em vários servidores que conversam entre si por meio de APIs. Os servidores que realizam as funções auxiliares ao servidor da aplicação principal são normalmente chamados de microsserviços (texto em inglês).

Para resumir, quando uma empresa oferece uma API aos seus clientes, isso significa apenas que eles criaram um conjunto de URLs dedicados que retornam respostas de dados puros — ou seja, as respostas não terão o tipo de carga de apresentação (quantidade de dados a serem transportados) que você esperaria de uma interface gráfica de usuário, como em um site da web.

É possível fazer essas solicitações com o seu navegador? Em geral, sim. Como a transmissão em HTTP de fato acontece no formato de texto, seu navegador sempre fará o melhor possível para exibir a resposta.

Por exemplo, você pode acessar a API do GitHub diretamente com seu navegador, mesmo sem precisar de um token de acesso. Aqui está a resposta em JSON que você recebe quando visita a rota de API de um usuário do GitHub em seu navegador (https://api.github.com/users/petrgazarov):

{  "login": "petrgazarov",  "id": 5581195,  "avatar_url": "https://avatars.githubusercontent.com/u/5581195?v=3",  "gravatar_id": "",  "url": "https://api.github.com/users/petrgazarov",  "html_url": "https://github.com/petrgazarov",  "followers_url": "https://api.github.com/users/petrgazarov/followers",  "following_url": "https://api.github.com/users/petrgazarov/following{/other_user}",  "gists_url": "https://api.github.com/users/petrgazarov/gists{/gist_id}",  "starred_url": "https://api.github.com/users/petrgazarov/starred{/owner}{/repo}",  "subscriptions_url": "https://api.github.com/users/petrgazarov/subscriptions",  "organizations_url": "https://api.github.com/users/petrgazarov/orgs",  "repos_url": "https://api.github.com/users/petrgazarov/repos",  "events_url": "https://api.github.com/users/petrgazarov/events{/privacy}",  "received_events_url": "https://api.github.com/users/petrgazarov/received_events",  "type": "User",  "site_admin": false,  "name": "Petr Gazarov",  "company": "PolicyGenius",  "blog": "http://petrgazarov.com/",  "location": "NYC",  "email": "petrgazarov@gmail.com",  "hireable": null,  "bio": null,  "public_repos": 23,  "public_gists": 0,  "followers": 7,  "following": 14,  "created_at": "2013-10-01T00:33:23Z",  "updated_at": "2016-08-02T05:44:01Z"}

O navegador parece que conseguiu exibir uma resposta em JSON sem problemas. Uma resposta em JSON assim está pronta para ser usada por seu código. É fácil extrair dados desse texto. Assim, você pode fazer o que quiser dos dados.

A tem a ver com "Aplicação"

Para encerrar, vamos examinar mais alguns exemplos de APIs.

"Aplicação" pode significar muitas coisas. Aqui estão algumas possíveis definições no contexto de API:

  1. Software com uma função específica.
  2. Todo o servidor, toda a aplicação ou apenas uma parte pequena de uma aplicação.

Basicamente, qualquer software que possa ser separado distintamente de seu ambiente, pode ser um "A" em API, tendo, provavelmente, algum tipo de API.

Vamos supor que você está usando uma biblioteca de terceiros no seu código. Assim que estiver incorporada no seu código, a biblioteca se torna parte da sua aplicação como um todo. Por ser um software específico, a biblioteca provavelmente terá uma API que a permite interagir com o resto de seu código.

Aqui está outro exemplo: no Design Orientado a Objetos, o código é organizado em objetos. Sua aplicação pode ter centenas de objetos definidos que podem interagir uns com os outros.

Cada objeto tem uma API — um conjunto de métodos públicos e propriedades que ele usa para interagir com outros objetos em sua aplicação.

Um objeto também pode ter uma lógica interna, que é privada, o que significa que está oculta do escopo do mundo exterior (e que não são uma API).

Com base no que tratamos neste artigo, espero que você tenha aprendido um significado mais amplo para API, bem como os usos mais comuns do termo nos dias de hoje.

Recursos interessantes (coisas que não mencionei aqui, mas que são muito legais, todos em inglês):

Um vídeo ótimo do YouTube falando sobre DNS (Domain Name System)

Questões básicas sobre o protocolo HTTP

Um vídeo incrível da Khan Academy sobre princípios do Design Orientado a Objetos