O potencial da API como um produto
Temos acompanhado o surgimento de muitas tendências de API ao longo dos anos. No entanto, poucos assuntos encapsulam tanto interesse quanto o conceito API como um produto.
Ao abrir a funcionalidade de software especializado por meio de uma API, as empresas podem comoditizar dados e componentes operacionais por chamada.
APIs da web comoditizadas ajudam as equipes de software a evitar reinventar a roda para o funcionamento comum. Pode ser qualquer coisa, desde pagamentos a geolocalização, inteligência artificial, dados meteorológicos, logins, mensagens e muito mais.
Você deve estar familiarizado com a frase “existe uma API para isso”. Estou entusiasmado com este formato, pois é indiscutivelmente uma encarnação mais sob demanda e em tempo real do Software como Serviço.
Muitas startups estão começando a tratar sua API como uma oferta básica, devido ao seu potencial de escalabilidade e crescimento explosivo.
Algumas empresas pioneiras em APIs até mesmo fizeram IPO nos últimos anos. Devido à sua natureza, as APIs têm muito a seu favor:
- Elas se encaixam na agenda de inicialização. Indiscutivelmente, as APIs apelam para os conceitos de especialização e interrupção.
- Elas são independentes de plataforma. Usando HTTP como um mecanismo de entrega, qualquer usuário desenvolvedor pode integrar APIs em seu aplicativo, independentemente da plataforma ou linguagem que está usando.
- Elas podem ser self-service. Se configurados corretamente com documentação e ambientes de teste incríveis, os portais de API fazem muito do trabalho inicial, exigindo o mínimo de suporte humano.
- APIs são padronizadas: os desenvolvedores estão familiarizados com APIs. Os produtos de API geralmente adotam um estilo REST, na linguagem JSON para HTTP. A especificação OpenAPI (anteriormente Swagger) também fez uma grande encruzilhada para documentar esses serviços.
No entanto, devemos reconhecer que mesmo o desenvolvimento de uma API pública, é necessário um esforço substancial para construir e manter uma API como um produto funcional e de autoatendimento.
Há muito a considerar. Você deve equilibrar a abertura com a cobrança pelo acesso. Os provedores devem encontrar seu modelo de freemium, limitação de taxa, cobrança por chamada ou preço de assinatura.
Você deve oferecer suporte a protocolos padrão e rastrear estilos de comunicação emergentes.
Também ajuda conhecer bem os usuários desenvolvedores, monitorar o uso da plataforma e otimizar para encontrar o modelo correto. E, projetar o programa é apenas o começo.
API como um produto, requerer experiência de desenvolvedor incomparável e alta estabilidade. O provedor também pode enfrentar desafios inesperados, como identificar usuários de spam .
A Intergate Integra via API seu ERP Totvs Protheus ou SAP Business One com qualquer sistema Especialista
Ou a API pode ter dificuldades para decolar e atrair o apoio de desenvolvedor necessário para sustentar um negócio. Mesmo que sua API não adote um modelo público, acredito que ainda ajuda a considerar como você pode se beneficiar de uma perspectiva de produto para integração.
Lembre-se de que este é um assunto muito novo e cheio de nuances. Os estilos de integração de software estão mudando, assim como os padrões de design de API. Essa evolução, combinada com a consolidação da indústria e novas camadas de abstração, pode afetar significativamente a estratégia geral dos produtos API para competir no mercado futuro.
Portanto, tome este texto com cautela e fique sempre atualizado com as forças em jogo. Com isso dito, boa leitura e boa sorte em sua jornada pela API!
FONTE: Blog Nordic APIs
