Como você, PM, já sabe o quanto as APIs podem agregar valor ao seu produto – ou ser o seu produto – conforme abordamos no artigo “Product Manager e APIs: qual a relação entre esses dois mundos?“. Vamos à alguns termos básicos e importantes para compor seu repertório (isso, é claro, de acordo com a minha opinião como PM de produtos de API).
Recapitulando
Já sabemos que API é um conjunto de lógicas que recebe uma entrada e fornece uma saída. Pegando como exemplo a API do Google Maps, na qual você fornece o endereço como entrada e recebe as coordenadas e longitude e latitude como saída.
Como a API fez isso? Está na programação e nas lógicas dela.
Conceitos básicos
Existem diferentes tipos de API, vou citar aqui as mais comuns que você encontrará no mercado
- APIs REST: essas são as APIs mais populares e flexíveis encontradas na Web atualmente. O cliente envia solicitações ao servidor como dados. O servidor usa essa entrada do cliente para iniciar funções internas e retorna os dados de saída ao cliente. A principal característica desse tipo de API é que os servidores não salvam dados do cliente entre as solicitações. As solicitações do cliente ao servidor são semelhantes aos URLs que você digita no navegador para visitar um site;
- APIs WebSocket: é um desenvolvimento de API da Web moderno que usa objetos JSON para transmitir dados. Uma API WebSocket oferece suporte à comunicação bidirecional entre aplicativos cliente e o servidor. O servidor pode enviar mensagens de retorno de chamada a clientes conectados, tornando-o mais eficiente que a API REST.
Entrada e saídas
Quando uma API é construída, para que ela funcione corretamente para o qual ela foi desenvolvida, precisamos definir as entradas e as saídas de cada uma delas.
Quando falamos de entradas (request), significa que aquela API, precisa receber determinadas informações dentro dos tipos específicos, para que essa API funcione corretamente. Ou seja, se pensarmos na API do Google Maps, ela está preparada para receber coordenadas (lat,lgn), no entanto, se você enviar uma imagem, a API não conseguirá realizar a seu propósito, e devolver a saída acordada.
Já quando falamos de saídas (response) são as informações que a API devolverá após realizar seu processamento.
Ou seja, uma vez que as entradas corretas foram passadas, a API realizará seu objetivo principal e retornará as informações corretas como saída.
Endpoints
Sempre que falamos em APIs, falamos de endpoints. Os endpoints são os pontos de contato finais no sistema de comunicação da API. Estes incluem URLs de servidores, serviços e outros locais digitais específicos de onde as informações são enviadas e recebidas entre sistemas.
Esses endpoints trabalham com o conceito de request e response, ou seja, você sempre envia uma solicitação para o endpoint e ele te retorna uma resposta. Todo esse contrato de como e quais informações devem ser enviadas em cada endpoint e o que você terá de retorno deverá estar dentro da sua documentação de API.
Embora as APIs sejam autoexplicativas, a documentação da API funciona como um guia para melhorar a usabilidade. APIs bem documentadas que oferecem uma série de funções e casos de uso tendem a ser mais populares em uma arquitetura orientada a serviços.
Escrever uma documentação de API faz parte do processo de gerenciamento de API. A documentação da API pode ser gerada automaticamente usando ferramentas ou escrita manualmente.
Agora vamos falar dos tipos de endpoints que sua API pode ter.
Para uma API ser funcional, cada endpoint precisa fazer exclusivamente uma única ação, e isso é acompanhado pelo verbo no qual ela pertence.
Os endpoints podem ser:
- POST: Usado para criar uma nova carga de informações dentro de seu serviço ou base de dados;
- GET: Usado para a leitura de informações. Este método permite que dados sejam pesquisados de acordo com o recurso inserido. Através deste método, o será retornará as informações consultadas;
- PUT/PATCH: É usado para atualizar ou editar as informações já existentes na base. O PUT é usado para alterar todas as informações, e o PATCH para realizar atualizações parciais dos dados;
- DELETE: Bem, como o nome diz, utilizado para apagar alguma informação de forma definitiva, ou seja, necessário avaliar se faz sentido para o seu negócio excluir o registro definitivamente.
APIs Privadas vs APIs Públicas
Uma API privada, é uma interface criada para ser usada dentro da organização, para que outros desenvolvedores e outros times dentro da empresa tenham acesso à informações e dados, ou seja, permitir que o time internos acessem as aplicações e possam aproveitar os sistemas existentes.
Mesmo sendo uma API privada, todos os conceitos de entradas e saídas são mantidos, para que o funcionamento seja da forma correta e esperada.
Quando falamos de uma API pública, significa que ela pode ser utilizada tanto por desenvolvedores de dentro da empresa que a criou como por qualquer outro desenvolvedor externo que deseja ter acesso a esse tipo de serviço.
Uma API pública, pode ser disponibilizada tanto no formato Open Source para a comunidade, ou como uma forma de receita da organização, onde são cobrados valores pela utilização, pelas chamadas, ou seja, a API se torna um produto para a empresa.
Concluindo
Bom, se você chegou até aqui, agora você sabe um pouco mais sobre o universo das APIs e pode levar mais desse conhecimento para o seu dia a dia.
É bem importante, como uma pessoa de Produto, ter esses conhecimentos sobre o universo das API. Assim os diálogos com o time de Engenharia podem ser mais robustos e as trocas com stakeholders claras e objetivas, uma vez que você passa a entender problemas de Engenharia. Da mesma forma, isso pode ser útil até mesmo para que você consiga enxergar oportunidades dentro da empresa e, quem sabe, criar um novo produto de API dentro da sua organização.
Leia também:
