Design: foco no consumo ou na API?

Qual a forma mais comum de se fazer design de APIs? Com certeza, o que é possível encontrar na imensa maioria das APIs (públicas, restritas ou privadas) é um uso extensivo do design focado em consumo.

Isto é, a empresa cria serviços e gera informações ao realizar seus negócios. Um dia, alguém percebe que esses serviços e dados podem ser consumidos de formas novas, talvez de forma que até a própria criadora não tenha imaginado antes.

Então, decide-se criar uma API! Tais serviços são segmentados em diferentes APIs e endpoints e um modelo de monetização é criado em cima disso, para que a empresa consiga bancar essa nova fonte de custos e, em especial, gere receita como nunca imaginou antes.

Porém, essa não é a única estratégia possível. Basta imaginar o cenário em que a empresa pretende construir um serviço e já sabe que ele terá potencial para ser aberto ou que ele irá substituir velhos paradigmas dentro da empresa.

Pronto! A API já está nascendo antes mesmo de qualquer serviço ser lançado.

Assim, quando seu serviço estiver pronto e for efetivamente lançado, já terá uma API fresquinha, cheia de oportunidades de integrações.

Aquela pessoa que vier a conhecer o seu serviço a partir do dia zero (o dia do lançamento) já pode pensar em oportunidades de validação e integração, porque seu serviço sempre ofereceu essa possibilidade, desde o momento em que foi concebido.

Eis o API First!

De onde surgiu essa ideia

Se você pensar bem, uma estratégia de API First não é nada de realmente brilhante. É simplesmente a forma como os negócios são feitos hoje em dia.

Em um mundo onde as pessoas podem acessar as informações oferecidas pelo seu serviço a partir de tantos tipos de hardware e software diferentes, é essencial que cada empresa saiba como se aproveitar disso para explorar nichos de mercado novos. Exploramos esse conceito no artigo sobre Omnichannel.

Um exemplo clássico disso é o Netflix, que surgiu como locadora de mídias físicas através da Internet e logo se alçou como principal provedora de entretenimento na forma de filmes e séries do mundo. Isso porque eles souberam satisfazer as necessidades de consumo através de tantos dispositivos quanto existem! Ou, como é dito: “Haverá Netflix em qualquer dispositivo que tenha tela!”.

Isso seria impossível sem a API. Ou seja, API sendo a base da estratégia de negócios. E em seguida, os negócios explodem. A ordem é importante: primeiro a API, depois o sucesso.

Além disso, a própria popularização de APIs permitiu que surgissem negócios novos totalmente enraizados em uma API. Ou seja, o negócio É a a API.

Essa é uma das formas mais interessantes de se monetizar uma API, pois a empresa que faz isso é essencialmente um SaaS. Dependendo das APIs oferecidas, torna-se rapidamente um PaaS (Plataform-as-a-Service). Fazendo isso, basta que os clientes consumam a API para que o fluxo de dinheiro comece.

Há muitas empresas cujo único produto é uma API. A provedora de serviços de telefone Twilio, por exemplo, atua somente através de uma API REST. Bem bacana!

E quando não fazer API First

Até aqui tudo pareceu muito bom.

Ter a API desde o início, servindo de base para negócios e aprendizados, realmente pode ser a vantagem competitiva em certos mercados de evolução rápida. Trata-se de oportunidades de inovação que muitos ainda não imaginaram.

Porém (e há sempre um porém), a API First pode não ser o caso para todos. Basta imaginar uma situação onde as lições aprendidas do consumo de um serviço serão utilizadas para criação de uma API no futuro.

O design de uma API envolve uma série de conhecimentos prévios, hipóteses que deverão ser feitas sobre seu público e a forma como o serviço será utilizado.

Lançar a API com essas hipóteses ainda cruas pode ser um erro. Então, leve isso em consideração ao criar o roadmap da sua API!

Fuja do legado!

Outra consideração importante a se fazer é que uma estratégia API First dá o poder nas mãos da escalabilidade e inovação. Isso quer dizer algo muito simples: seus serviços nascem livres e soltos, prontos para integrações de diversos tipos. Esse é o caminho contrário de uma abordagem arquitetural que leva a empresa a construir sistemas com pouca (ou nenhuma) oportunidade de escalar e evoluir, criando o que costumamos chamar de “sistema monolítico”.

Quem dá consultoria em SOA (Service Oriented Architecture) e vemos isso o tempo todo! E depois que um sistema desse está instalado nas entranhas da organização, quebrá-lo em serviços e até oferecê-lo em forma de API para integrações internas é muito difícil.

Para ser mais específico, através de uma modulação da infraestrutura com APIs sólidas, desenvolvedores e parceiros (internos e externos) podem criar aplicações para entrar em produção de uma maneira muito mais segura e com maior confiabilidade.

Talvez o nosso webinar de microservices seja de grande ajuda para tentar granularizar sistemas legado e trazer mais inovação e escalabilidade à serviços que antes eram rígidos demais.

Veremos cada vez mais API First

Considerando tudo isso, a mudança do paradigma para API First permite que qualquer sistema seja muito mais flexível, respondendo mais rapidamente e se comportando de maneira mais dinâmica para se adequar a propósitos não planejados anteriormente. Por isso, acredito que o paradigma API first seja mais escalável por natureza.

Ao criar um novo serviço, o design da API tem uma grande importância. Para o serviço seguir para produção, isso significa que a API deve estar bem documentada, fácil de usar, com monitoração, segura e preparada para escalar.

O interessante é que todas essas funções estão presentes em soluções de gerenciamento de APIs.

A  partir disso, cada empresa tem a liberdade (e a responsabilidade) de planejar sua própria estratégia. Basta que leve em consideração a escalabilidade e algumas lições aprendidas sobre seu produto e serviços.

Em ambos os casos, o consumo da sua API estará apenas a um convite (ou token de acesso) de distância.