A API: o garçom que conecta tudo

O mensageiro entre front-end e back-end

Na página anterior, você conheceu as três peças fundamentais de um produto digital: front-end, back-end e banco de dados. Agora vem a peça que junta esse quebra-cabeça: a API.

Você provavelmente já ouviu a analogia do garçom, e ela funciona bem como ponto de partida. A API é como o garçom do restaurante: anota o pedido do cliente (front-end), leva para a cozinha (back-end), e traz o prato pronto de volta. Mas vamos além dessa analogia, porque entender o que uma API realmente é vai te dar muito mais repertório.

Afinal, o que é uma API?

API significa Application Programming Interface, ou Interface de Programação de Aplicação. Eu sei, o nome é intimidante. Mas pensa comigo: a palavra-chave aqui é interface. Você, como designer, conhece bem esse conceito. Uma interface é um ponto de contato entre duas coisas. A interface do usuário (UI) é o ponto de contato entre a pessoa e o software. A API é o ponto de contato entre dois softwares.

Uma API é um conjunto de regras que define como um programa pode pedir informações ou serviços a outro programa. Ela estabelece: quais pedidos são permitidos, como eles devem ser feitos e em que formato a resposta vai chegar. É como um contrato. O front-end sabe exatamente como pedir, e o back-end sabe exatamente como responder.

O ciclo pedido-resposta

Na prática, o funcionamento de uma API segue um ciclo simples: pedido (request) e resposta (response). Funciona assim:

1. O usuário faz algo na interface, por exemplo, clica em "Buscar".
2. O front-end monta um pedido e envia para a API: "quero os produtos que contêm 'tênis'".
3. A API leva esse pedido para o back-end.
4. O back-end consulta o banco de dados, processa a informação.
5. O back-end monta uma resposta e devolve pela API.
6. O front-end recebe a resposta e exibe o resultado na tela.

Esse ciclo acontece sempre que a interface precisa de algo que ainda não tem: buscar dados novos ou salvar alguma coisa. Uma busca, um login, um scroll que carrega mais conteúdo, tudo isso passa por esse fluxo. Mas nem toda interação chama a API: quando a ação só mexe no que já está na tela (abrir um menu, expandir um card, conferir se um campo obrigatório foi preenchido), o front-end resolve sozinho, sem ir ao servidor. É por isso que algumas ações respondem na hora e outras precisam de um estado de carregamento.

APIs que você já usa (mesmo sem saber)

Você interage com APIs o tempo todo, mesmo como designer. Alguns exemplos que estão no seu dia a dia:

• Login social: quando você faz login em um site usando sua conta do Google ou do Facebook, a aplicação está usando a API dessas plataformas para verificar sua identidade. Você não precisa criar mais uma senha. Isso é uma API trabalhando.
• Google Fonts: sabe quando você escolhe uma fonte no seu protótipo e ela carrega direto da internet? O Figma (ou o navegador) está fazendo um pedido para a API do Google Fonts: "me manda a fonte Inter, peso 400". E a API responde com o arquivo da fonte.
• Figma: os componentes que você puxa da biblioteca do seu time? Eles chegam via API. Quando você exporta um frame como imagem? API. Quando um plugin roda no Figma? Ele está usando a API do Figma para acessar e manipular os dados do seu arquivo.
• Mapas: quando um app mostra sua localização em um mapa, ele está usando a API do Google Maps (ou similar). O app pede: "me dá o mapa dessas coordenadas". A API responde com a imagem do mapa.

E por que isso importa para você como designer?

Porque as limitações e possibilidades da API definem o que você pode ou não projetar. E isso não é teoria. É o seu dia a dia:

• Se a API só retorna 20 resultados por vez, você precisa projetar paginação ou scroll infinito.
• Se o servidor demora 3 segundos para responder, você precisa projetar um estado de carregamento convincente, um skeleton screen, uma mensagem de espera.
• Se o banco não tem campo para foto de perfil, não adianta colocar avatar no layout. Não existe a informação para mostrar ali.
• Se a API de pagamento não suporta Pix, você não pode oferecer Pix como opção no checkout.

Entender APIs não é virar dev. É ampliar seu repertório para tomar decisões de design mais inteligentes e para ser ouvido(a) quando o time técnico estiver decidindo algo que impacta diretamente o usuário. Quando você sabe perguntar "a API suporta isso?", você deixa de ser o designer que recebe restrições e passa a ser o designer que participa das decisões.