Descoberta/Pesquisa:
Quando você está construindo um novo Produto, Funcionalidades ou uma API, você está tentando resolver um problema. Para isso você precisa primeiramente entender o problema. Certo?Então, sempre tente ter o domínio de conhecimento sobre esse problema. Tente entender qual o problema que você está tentando resolver, para quem isso está sendo desenvolvido, etc. Esclareça os casos de uso e requisitos. Pesquise se existem soluções já criadas para entender como resolveram o mesmo problema e como você pode aprender com esta solução observando a arquitetura/decisões técnicas. Repasse o conhecimento para a equipe e todos os interessados. As diferentes perspectivas te dará uma visão mais ampla sobre a sua API e sobre as decisões técnicas que você está planejando fazer a partir deste ponto.
Esta etapa resultará em muita informação desestruturada, redundâncias e conflitos entre casos de uso e requisitos. Portanto, na próxima etapa é o momento de estruturar essas informações para que você possa tomar as melhores decisões sobre a sua API.
Definição/Síntese:
A partir dos dados brutos, encontre tendências e insights que apliquem para diferentes usuários e cenários. Este estágio também é o momento certo para sinalizar qualquer dependência que sua API pode ter com outro serviço, o que é bem comum em uma arquitetura de micro-serviços. Defina seus modelos de recursos e os relacionamentos entre eles. Isso irá te ajudar a identificar todos os recursos que você precisa expor nas APIs. É preciso também, descrever todos os comportamentos e expectativas da API. Assim quem for utilizar a API não precisará fazer nenhuma suposição. Ao fazer isso será possível identificar o conjunto de lógicas de negócio que farão parte do serviço ou da solução para o cliente.
Desenvolvimento/Ideação:
Uma vez que estiver claro "O que é preciso alcançar" com a utilização das APIs, chega o momento de projetar essa APIs você pretende comunicar e fornecer com as mesmas. Documentar as APIs utilizando ferramentas como OpenAPI/Swagger, RAML, ect, é uma ótima maneira de expressar a importância dos aspectos de uma API. Especialmente as decisões relacionadas ao 'frontend' e de arquitetura, os quais são visíveis para quem consome e podem ser verificadas na documentação. Uma desvantagem desse tipo de documentação é que elas podem ser muito técnicas, demasiadamente detalhadas e de difícil colaboração. Uma alternativa para isso é importar do Swagger, OpenAPI ou RAML a especificação para dentro de uma ferramenta client REST, como o Postman que oferece suporte ao desenvolvedor de API.
Entrega/Implementação: Após você obter sucesso no planejando sua API é hora de começar a implementação. Mas antes de iniciar a codificação das APIs é preciso estabelecer alguns testes para as APIs, para assim garantir que qualquer mudança durante o desenvolvimento acordado nas requisições e respostas, estes testes comecem a falhar. Então é possível atualizar o código ou comunicar todos os efeitos para o time. No Postman existe o conceito de colaboração, isso promove constante visualização entre os participantes e muitos feedbacks podem ser aproveitados dessa interação.