✔ Experiência unificada – Usuários do produto encontram a documentação no mesmo local, sem precisar buscar em fontes externas.
✔ Maior alinhamento com a evolução do produto – Mudanças na API acompanham "automaticamente" as mudanças no produto.
✔ Facilidade de acesso para clientes – Se a API for utilizada por clientes do próprio produto, o acesso integrado simplifica a adoção.
✔ Melhor suporte e integração – Pode estar conectada a fóruns, FAQs e suporte técnico dentro do mesmo ecossistema.
❌ Desvantagens:
✖ Pode dificultar a adoção por terceiros – Se a API for aberta, desenvolvedores externos podem ter dificuldade em encontrá-la.
✖ Menos flexibilidade na organização da documentação – Pode ser difícil criar uma documentação modular e expansível dentro da estrutura do produto.
✖ Risco de desatualização – Caso o foco esteja no produto principal, a documentação da API pode ficar desatualizada.
✖ Estrutura pré-definida com base na documentação do PDV - Uma documentação pensada no negócio em si ao invés de API
Modelo 2 →
Image Added
✔ Documentação mais resumida
✔ Pensada nos tipos de dados que o PDVOmni pode receber da retaguarda
✔ Processo inicial
✔ Fluxos de Baixa
✔ Processos Online (pendente incluir)
Pontos de Melhoria
Estrutura separado pelos tipos de dados, sendo que o PDVSync é separado por micros serviços
Em cada tipo de dados existe uma quantidade enorme de informações do PDV na primeira aba + as informações da API, pode ser tornar confuso para o usuário
Necessidade de dar foco para a API e foco para o PDV quando o usuario for procurar uma informações