Saltar para o conteúdo principal
Design e desenvolvimento de APIs

Design e desenvolvimento de APIs

Desenhamos e construímos APIs fáceis de integrar, com contratos claros, versionamento sensato, documentação a sério e segurança integrada. Uma API que alimenta as suas próprias apps ou integrações de terceiros é um produto em si mesma, e tratamo-la como tal.

O que está incluído

Uma API é um produto, não uma reflexão tardia

Uma boa API é consistente, bem documentada e difícil de usar mal. É isso que separa uma integração que demora uma tarde de uma que demora um mês. Desenhamos primeiro o contrato, protegemo-lo devidamente e documentamo-lo para que outros possam trabalhar sobre ele sem adivinhar.

No âmbito
  • Design e implementação de APIs REST e gRPC
  • Design contract-first com documentação OpenAPI
  • Autenticação e autorização bem feitas (OAuth, tokens, scopes)
  • Versionamento, rate limiting e paginação
  • Webhooks e integração orientada a eventos
  • Integração e orquestração das APIs de terceiros de que depende
Como trabalhamos

Como construímos APIs

Contract-first, seguras por defeito e documentadas ao longo do caminho, para que quem as consome (incluindo a sua própria equipa daqui a um ano) possa confiar nelas.

  1. 1

    Contrato primeiro

    Desenhamos a superfície da API e acordamos o contrato (recursos, métodos, erros) antes de escrever a implementação.

  2. 2

    Construir e proteger

    Uma implementação idiomática em Go ou Node.js, com autenticação, autorização e validação de entrada integradas desde o início.

  3. 3

    Documentar

    Documentação OpenAPI rigorosa gerada a par do código, para que os docs nunca se desviem da realidade.

  4. 4

    Testar e reforçar

    Testes de contrato e de integração, rate limiting e uma revisão de segurança. É no controlo de acessos que as APIs mais vezes falham.

  5. 5

    Versionar e operar

    Uma estratégia de versionamento que não quebra os consumidores existentes, mais métricas e logging para que possa ver como é usada.

Entregáveis

O que recebe

Uma API sobre a qual outros podem construir com confiança: documentada, protegida e versionada.

O que recebe
  • Uma API REST ou gRPC documentada
  • Documentação OpenAPI / de schema que se mantém sincronizada com o código
  • Autenticação e autorização com scoping adequado
  • Rate limiting, paginação e uma estratégia de versionamento
  • Testes de contrato e de integração, mais uma revisão de segurança
  • Métricas, logging e uma transição para a sua equipa
Stack e abordagem

A toolchain de APIs

REST, gRPCOpenAPIGo, Node.jsOAuth, JWTPostgreSQLRate limiting, webhooks

Versionada, documentada e coberta por testes de contrato: a disciplina que permite que outros dependam da sua API.

Perguntas

Perguntas sobre desenvolvimento de APIs

REST ou gRPC?

O REST é a escolha certa por defeito para APIs públicas e voltadas para o browser: universal, cacheável e fácil de consumir. O gRPC destaca-se no tráfego interno entre serviços, onde interessa tipagem forte, streaming e menos overhead. Muitos sistemas usam ambos. Escolhemos com base em quem consome a API e como, e não na moda.

A API vai estar devidamente documentada?

Sim, e a documentação é gerada a partir do contrato, por isso não se pode afastar da implementação sem que alguém dê por isso. Quem consome a API recebe documentação OpenAPI rigorosa que pode ler, experimentar e usar para gerar clientes. É isso que transforma uma integração de um mês numa tarde.

Como protegem a API?

A autenticação e a autorização são desenhadas desde o início: tratamento adequado de tokens, permissões restritas e validação de entrada em cada endpoint. O controlo de acessos deficiente é a vulnerabilidade de API mais comum, por isso testamos a autorização explicitamente em vez de presumir que a framework trata disso.

Conseguem integrar as APIs de terceiros de que dependemos?

Sim. Integramos e orquestramos as APIs externas de que o seu produto depende, como pagamentos, identidade ou mensagens, com retries sensatos, tratamento de erros e uma abstração limpa, para que uma mudança de fornecedor não se propague por toda a sua base de código.

Construa uma API que outros adoram usar.

Diga-nos o que a sua API precisa de fazer e quem a vai consumir. Desenhamo-la contract-first e construímo-la para durar.