Série API Connect — Primeiros passos
A primeira parte dessa série pode ser encontrada no link abaixo:
Como dito anteriormente, o API Connect atua como um API Manager, proporcionando aspectos como:
- Criação de especificações de APIs em Swagger;
- Execução de APIs;
- Gerenciamento e monitorameto de utilização de APIs;
- Segurança e Logs;
É possível criar APIs em REST ou SOAP seguindo-se a especificação Swagger… sim… você consegue criar uma API SOAP com Swagger ou na verdade, quase isso…
O API Connect utiliza o Swagger como meio de especificar e executar as APIs. Pode parecer confuso, mas quando iniciarmos alguns exemplos isso ficará mais claro, bem como o papel do DataPower nessa história. No caso de APIs SOAP, o WSDL ainda sim é o ponto de início para a criação da API, porém, a partir desse primeiro input o API Connect encapsula o contrato WSDL com o Swagger. Mais adiante falaremos das desvantagens e complicações dessa abordagem.
Tenho utilizado o Swagger em outros projetos, e tenho gostado muito, seja pela documentação, seja pelo conceito de API First. Apesar de não haver unanimidade quanto a especificação de APIs REST, seja com APIary, Swagger ou RAML, passei a ter uma simpatia pelo Swagger por conta da facilidade de integração com o Spring em projetos Java, Groovy e agora com Kotlin também, o que também não quer dizer que ele é uma solução livre de problemas, complexidades e nem de críticos.
O ponto aqui é entender que o API Connect SÓ dá suporte ao Swagger como implementação, então, não vai ter muito para onde correr. Por mais que a interface provisione suporte a criação via componentes através do arrastar e soltar, ainda sim, é interessante ter em mente noções da especificação Swagger, por alguns problemas (que eu sempre tenho, e espero que apareçam em nossos exemplos) oriundos da geração de código por colocar componentes e configurá-los.
Outro ponto interessante é perceber que programação com o API Connect a nível de código se limita a GatewayScripts com JavaScript e XSLTs. Claro que existem ainda uma série de componentes que facilitarão nosso desenvolvimento, como if, switch, throws, map, invoke, etc, veremos mais sobre isso em outros posts.
Ainda com relação ao API Connect, é interessante notar ainda que existe uma diferença de perfis de usuários da solução:
- Um perfil administrador;
- Um perfil de desenvolvimento de APIs;
- Um perfil de consumo de APIs;
- Dentre outros.
Falaremos mais sobre cada um desses aspectos nos próximos posts, bem como os ambientes de atuação de cada um deles, como por exemplo, o Portal do Desenvolvedor, local onde são gerenciadas Organizações para o consumo de APIs, bem como subscrição por parte dos consumidores.
Acredito que algumas abordagens ficarão mais claras com exemplos, então vou parar por aqui, e me preparar para o próximo post em que instalaremos o API Connect via Docker, até lá…
