O que é uma API? Em inglês por favor.

Antes de aprender a desenvolver software, API soava como uma espécie de cerveja.

Hoje, uso o termo com tanta frequência que, na verdade, recentemente tentei solicitar uma API em um bar.

A resposta do barman foi lançar um 404: recurso não encontrado.

Conheço muitas pessoas, tanto trabalhando com tecnologia quanto em outros lugares, que têm uma ideia um tanto vaga ou incorreta sobre o que significa esse termo bastante comum.

Tecnicamente, API significa Interface de Programação de Aplicativo . Em algum ponto ou outro, a maioria das grandes empresas criou APIs para seus clientes ou para uso interno.

Mas como você explica a API em inglês simples? E há um significado mais amplo do que aquele usado em desenvolvimento e negócios? Primeiro, vamos voltar e ver como a própria web funciona.

WWW e servidores remotos

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

Cada página da Internet é armazenada em algum lugar em um servidor remoto. Afinal, um servidor remoto não é tão místico - é apenas uma parte de um computador localizado remotamente que é otimizado para processar solicitações.

Para colocar as coisas em perspectiva, você pode ativar um servidor em seu laptop capaz de servir um site inteiro para a Web (na verdade, um servidor local é o que os engenheiros usam para desenvolver sites antes de liberá-los para o público).

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

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

Uma API não é o mesmo que o servidor remoto - em vez disso, é a parte do servidor que recebe solicitações e envia respostas .

APIs como uma forma de atender seus clientes

Você provavelmente já ouviu falar de empresas que empacotam APIs como produtos. Por exemplo, Weather Underground vende acesso a sua API de dados meteorológicos.

Cenário de exemplo: o site da sua pequena empresa tem um formulário usado para inscrever clientes para compromissos. Você deseja dar aos seus clientes a capacidade de criar automaticamente um evento do Google Agenda com os detalhes desse compromisso.

Uso da API: a ideia é fazer com que o servidor do seu site converse diretamente com o servidor do Google com uma solicitação para criar um evento com os detalhes fornecidos. Seu servidor então receberia a resposta do Google, processaria e enviaria informações relevantes ao navegador, como uma mensagem de confirmação para o usuário.

Alternativamente, seu navegador pode frequentemente enviar uma solicitação de API diretamente para o servidor do Google, ignorando seu servidor.

Como a API do Google Agenda difere da API de qualquer outro servidor remoto por aí?

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

Para renderizar toda a 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 Google Agenda retornaria apenas os dados - provavelmente em um formato como JSON .

Se o servidor do seu site está fazendo a solicitação de API, então o servidor do seu site é o cliente (semelhante ao seu navegador ser o cliente quando você o usa para navegar para um site).

Da perspectiva dos usuários, as APIs permitem que eles concluam a ação sem sair do seu site.

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

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

Não é incomum que as equipes de desenvolvimento dividam seus aplicativos em vários servidores que se comunicam por meio de APIs. Os servidores que executam funções auxiliares para o servidor de aplicativos principal são comumente chamados de microsserviços .

Para resumir, quando uma empresa oferece uma API para seus clientes, isso significa apenas que eles construíram um conjunto de URLs dedicados que retornam respostas puras de dados - o que significa que as respostas não conterão o tipo de sobrecarga de apresentação que você esperaria em um interface gráfica do usuário, como um site .

Você pode fazer essas solicitações com seu navegador? Freqüentemente, sim. Como a transmissão HTTP real ocorre em texto, seu navegador sempre fará o melhor que pode para exibir a resposta.

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

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "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 ter se saído bem ao exibir uma resposta JSON. Uma resposta JSON como essa está pronta para uso em seu código. É fácil extrair dados deste texto. Então você pode fazer o que quiser com os dados.

A é para “Aplicação”

Para encerrar, vamos adicionar mais alguns exemplos de APIs.

“Aplicativo” pode se referir a muitas coisas. Aqui estão alguns deles no contexto da API:

  1. Um software com função distinta.
  2. O servidor inteiro, o aplicativo inteiro ou apenas uma pequena parte de um aplicativo.

Basicamente, qualquer pedaço de software que pode ser distintamente separado de seu ambiente pode ser um “A” na API e provavelmente também terá algum tipo de API.

Digamos que você esteja usando uma biblioteca de terceiros em seu código. Depois de incorporada ao seu código, uma biblioteca se torna parte do seu aplicativo geral. Por ser um software distinto, a biblioteca provavelmente teria uma API que permite que ela interaja com o resto do seu código.

Aqui está outro exemplo: No projeto orientado a objetos , o código é organizado em objetos. Seu aplicativo pode ter centenas de objetos definidos que podem interagir uns com os outros.

Cada objeto tem uma API - um conjunto de métodos e propriedades públicos que ele usa para interagir com outros objetos em seu aplicativo.

Um objeto também pode ter uma lógica interna que é privada, o que significa que éescondidodo escopo externo (e não de uma API).

Pelo que cobrimos, espero que você retire o significado mais amplo de API, bem como os usos mais comuns do termo hoje.

Recursos interessantes (coisas que deixei de fora, mas ainda são muito legais):

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

Noções básicas de protocolo HTTP

Um vídeo incrível da Khan Academy sobre princípios de design orientado a objetos