APIs são fundamentais em qualquer processo de transformação digital e, para que sejam adotadas e efetivas, precisam ser bem projetadas. Infelizmente, projetos infelizes acabam implicando em menos adesão e eficácia, desperdiçando recursos. No nosso entendimento, uma boa API começa pela definição de seu propósito.
De forma geral, em ambientes corporativos complexos, concordamos e recomendamos a categorização, já bem conhecida, de APIs em dois grupos distintos:
- APIs externas – que fornecessem acesso para dados e funcionalidades para aplicações usadas na “ponta”, além dos “muros” da organização atendendo clientes, fornecedores e parceiros. Geralmente, essas APIs podem serem consumidas por aplicações criadas por desenvolvedores que não trabalham na empresa.
- APIs internas – expondo dados e funcionalidades dos sistemas de base – desenvolvidos internamente ou externamente, legados ou não – expondo, muitas vezes, detalhes de design. Essas APIs são projetadas para serem consumidas por código escrito “dentro de casa”, por desenvolvedores que trabalham “dentro” da empresa.
Gostamos dessa classificação por ela ajudar, inclusive, na organização dos times e na definição dos skills dos envolvidos.
Veja também
Nesse modelo, as APIs externas, destinadas a interagir “na ponta”, precisam ser customer-centric. Ou seja, ajustadas para atender da forma mais pragmática possível as demandas das aplicações consumidoras. Enquanto isso, as APIs internas, que expõe dados e comportamentos dos sistemas de base (geralmente do backoffice), com frequência legadas, preservam o mesmo “espírito” desses sistemas.
Os processos de desenvolvimento das APIs externas guardam muitas semelhanças com práticas de UX. Entretanto, voltadas a facilitar a vida dos desenvolvedores e não de usuários finais. Nas APIs internas, é fundamental preservar o domínio de cada aplicação sendo exposta.
A orquestração da interação entre as APIs internas e externas é idealmente realizada em uma camada de mediação – agrupando requests, sequenciando interações, etc.
Essa categorização, quando aplicável, tem potencial para aumentar significativamente a eficácia das APIs, tanto internas quanto externas, favorecendo o aumento da adesão no consumo. Por serem bem determinadas, elas também colaboram para que projetos que não trafeguem dados desnecessários e resguardam os sistemas internos, resultando em mais segurança. Em função da especialização, há notória possibilidade de redução dos custos totais.
Entendi que essa classificação seja é bom e faz sentido para uma empresa. No entanto acredito que os custos sejam maiores e não menores visto que você terá desenvolvimento maior para expor eventualmente a mesma coisa para “canal” diferente e também terá os custos de manter esses dois ou mais APIs equalizadas frente a alterações. Não podemos esquecer os custos de infra para eles . Por isso entendo que a classificação de interna e externa seja válida e funcione bem, porém isso pode ser derivado os APIs por canal, onde acredito que possa não ser ser tão bom até mesmo para governar. O que acham sobre isso?
Acredito que é uma complexidade acidental classificar as API em externas e internas em uma situação onde os dados expostos são iguais. Eu faria todas as API pensando no consumo externo, dessa forma atenderia todos os clientes internos e externos iguais.