A partir desse post, entraremos em uma parte mais técnica dos Blocos de Construção de uma API. Nos artigos anteriores, vínhamos falando, principalmente, de Marketing, Negócios e Relacionamento.

Como você já deve ter notado, desenvolvedores têm um papel crucial em todas as etapas. Até agora, eles vinham sendo principalmente objetos das suas ações e escolhas, enquanto criador e gerente da API. De agora em diante, eles terão uma relevância mais direta na construção da API, influenciando as principais tecnologias e plataformas presentes na sua API. Veremos como em detalhes.

Caso você tenha chegado agora, não precisa sair fuçando o blog, os posts anteriores dessa série estão aqui:

• I – Onboarding;
• II – Documentação;
• III – Materiais Educativos;
• IV – Comunicação com devs e parceiros;
• V – Conta do Desenvolvedor;
• VI – Monetização e serviços.

Quer ter todos os posts, reunidos, arrumados e organizados, para o seu conforto? Então baixe o Ebook de Blocos de Construção! Clique aqui ou na imagem abaixo:

Tudo certo com os artigos passados? Conferiu o Ebook? Então vamos ao post dessa semana.

Para começar o debate sobre os meandros da API, algumas bases de Design de APIs. Lembrando que se você quiser se aprofundar no assunto, a Sensedia tem alguns conteúdos bem bacanas.

O que você acharia de algum esporte que realizasse seus jogos e treinos no mesmo dia e local? Seria como alguns pilotos de fórmula 1 fazendo as voltas de teste, outros fazendo as voltas de qualificação e ainda alguns na corrida valendo pontos, tudo ao mesmo tempo e na mesma pista. Ou dois times de futebol travando uma partida no Maracanã enquanto um terceiro treina e a torcida de um quarto ensaia seus gritos e canções. Você imagina isso acontecendo?

Se não faz sentido imaginar cenários assim, por que algumas apps devem realizar suas chamadas em produção enquanto outros testam e experimentam, tudo no mesmo ambiente? Se algum dev erra a implementação do código de sua app e sobrecarrega a API, todo mundo cai junto? (Se uma única app é capaz de derrubar a sua API inteira, então você tem uma API com falhas de design e ambiente desprotegido. Confira os conteúdos de Design e Gerenciamento de APIs para ver como corrigir essas falhas).

Portanto, fica claro que devem haver diferentes ambientes, em que algumas apps estão sendo testadas enquanto outras são expostas e podem ser baixadas, usadas e aproveitadas. Veja:

Ambiente de Produção

Por definição, esse ambiente é aquele em que a equipe de desenvolvimento coloca em operação o software, para que seus usuários finais possam desfrutar desse software. Para sua API, esse é o ambiente em que seus recursos (ou endpoints) estão disponíveis, as apps realizam chamados e os usuários dessas apps acessam sua API.

Os usuários, muitas vezes, não tem consciência de que estão acessando uma API, uma vez que a app funciona como interface e abstrai essa relação. Na prática, isso significa que não faz sentido falar em uma API exposta que não tenha um Ambiente de Produção. Essa é a raiz da exposição. Portanto, toda API, seja aberta ou restrita ao uso de parceiros, tem um Ambiente de Produção.

Sandbox/Ambiente de Testes

Esse é o espaço em que os developers irão brincar com sua API, conhecer os recursos disponíveis, tratar os retornos, ou seja, colocar em ordem tudo que precisa estar funcionando para o lançamento da app. Praticamente toda app precisa passar por aqui, para que os devs tenham certeza de que está funcionando de acordo com o esperado. Porém, nem toda API tem uma Sandbox, o que é um empecilho à realização dos testes de desenvolvimento e homologação.

Apesar de ser um custo inicial a mais no Design da API, a Sandbox se mostra um ótimo investimento pois reduz o atrito inicial para o desenvolvimento de apps e, é claro, diminui a quantidade de chamados abertos no seu serviço de Suporte. Portanto, ter um Ambiente de Testes na sua API é uma decisão bastante sábia.
Exemplos: Gengo, eBay, Twilio.

Simulador

Trata-se de um ambiente de sandbox com esteróides. Esse é um terceiro ambiente, que apesar de não ser tão fundamental quanto os dois acima, é uma aquisição interessante à qualquer API. Nele, existem coleções de dados pré-acumuladas, assim como testes definidos para algumas experiências que possam causar dificuldades à implementação de apps. Essa pode ser outra oportunidade de reduzir os custos de operação de Suporte e tornar a implementação de apps mais produtiva.

Ficamos por aqui essa semana. Na semana que vem, vamos foca em implementação e gerenciamento de código, em especial algumas bibliotecas e SDKs. Nos vemos lá!

Gostou desse artigo? Confira a parte VIII: Gerenciamento de Código, clicando aqui, ou na imagem abaixo: