Agrupadores de APIs e futuro do projeto Tools

Propósito

Esse Grooming abordou assuntos diversos, que podem ser agrupados da seguinte forma:

• Preocupações relacionadas aos padrões atuais dos agrupadores de APIs, e a maneira como a ferramenta de agrupador está atuando.
• Futuro das ferramentas de monitoramento e configuração
• Retomar desenvolvimento da ferramenta de edição de APIs

Ata

Foram apresentadas as preocupações em relação ao agrupamento de APIs:

• Autorização: No WSO2, todos teriam que ter acesso ao segmento como um todo, ao invés de APIs individuais.
• Vínculo com backend: Todas as APIs agrupadas precisariam estar disponibilizadas em um mesmo host através da mesma porta, ou a mesma teria que referenciar um service discovery

Após discussão, as respostas foram as seguintes:

• Autorização: É feita na camada do serviço, e não do gateway
• Vínculo com backend: De fato um problema. Foi preciso criar um novo nível na API, para fazer parte do "context" da API: Domínio. 
  • Esse Domínio fará sentido de existir tanto na URL quanto em uma propriedade de documentação.

Foi apontado que nossa área não tem mais foco em ferramentas de EAI, estas estão passando para Framework (Monitor e configurador).
Sendo assim, temos apenas que atuar em bugs e não mais em inovações.

Nosso foco está voltado para microserviços/APIs e arquitetura.

A ferramenta de edição de APIs foi colocada como algo importante de ser atuado, e dentro do nosso foco.
Sobre esse assunto, os seguintes pontos foram colocados:

• É importante que seja possível importar/exportar OpenAPI
• Considerar/estudar a possibilidade de alguma integração/reutilização das validações fornecidas pelo validador
• Considerar a possibilidade de controlar permissões. Ex: Uma pessoa de RM só pode alterar documentação de RM para uma API existente.
• O desenvolvimento da ferramenta deve, preferencialmente, ser feito de forma colaborativa dentro da TOTVS, permitindo a contribuição de outras áreas.

Conclusões

• Foi adicionado o conceito de "Domínio" para novas documentações do OpenAPI
  • O padrão de URL torna-se "/api/{agrupador}/{dominio}/{versao}/{recurso}"
    • Apenas para APIs criadas a partir desse momento. As que foram definidas sem o conceito de domínio não sofrerão nenhuma breaking change.
  • Propriedade "Domain" é adicionada em "Info" → "X-totvs" → "Message Documentation"
  • As documentações correspondentes (Guia de APIs e Guia de Integrações) devem ser ajustadas para evidenciar a inclusão do novo conceito.
• A ferramenta de agrupador não precisará ser alterada
• Cada cliente só pode ter um determinado domínio apontando para uma única linha (Protheus, RM, Datasul...)
• O API Reference vai ganhar um novo filtro, com base na propriedade "Domain"
• TryOut do API Reference está planejado para o segundo semestre, quando teremos os ambientes de experimentação disponíveis.
  
  • Não existirá UX para o frontend, a intenção é copiar a do swagger e alterar o padrão de cores e fontes
• O configurador unificado tornou-se uma ferramenta de configuração de pacotes prontos, não haverá inovações. As issues de backlog relativas a inovações no configurador serão canceladas.
• Os próprios ERPs vão fornecer o necessário para edições, e outras operações avançadas, das configurações do EAI
• Não haverá inovações no monitor
• Devemos iniciar o desenvolvimento da ferramenta de edição de APIs

Ações

• Adicionar, em nova versão do Guia de Implementação de APIs, a necessidade do domínio na URL do endpoint.

• Adicionar no Guia de Implementação de Integrações a necessidade de inserir o Domain no X-Totvs do OpenAPI.

• Gerar a propriedade "Domain" automaticamente em todas as documentações de OpenAPI's existentes. Esse deve ser preenchido com o nome do arquivo. Isso deve ser feito para garantir a compatibilidade no API Reference.

• Adicionar validação que exige a propriedade "Domain"
• Criar filtro por Domínio no API Reference
• Planejar o desenvolvimento da ferramenta que facilita a modelagem da documentação de APIs, incluindo tarefa na próxima sprint.
• Cancelar issues de inovação relativas ao Monitor e Configurador Unificado.
• Negociar com a equipe de Frame do Datasul o desenvolvimento de tela de configuração de EAI no Datasul Novo Frame.