Requisição HTTP
Antes de avançarmos, é importante entender o que é uma requisição HTTP. Para isso, eu vou dar um exemplo, imagina que você está com o teu browser aberto, Chrome, Firefox ou Edge e você digita no endereço www.google.com e apertar ENTER. Quando você faz para esta ação, por debaixo dos panos, o que está ocorrendo é uma requisição HTTP. Esta requisição é enviada para um servidor onde está o hospedado Google, digamos assim e este servidor vai receber esta requisição e vai devolver um response, que é uma resposta.
Porém, as coisas não acontecem de forma tão direta, porque muitas vezes ou geralmente os servidores, quando acessados, eles estão muito distantes da nossa região, da nossa localidade. Então, o que ocorre é que, quando uma requisição é feita essa requisição, ela passa por roteadores intermediários que vão levando esta informação até o servidor final.
Então, se você está em um determinado estado do Brasil, por exemplo. E você faz uma requisição HTTP para um site Internacional existe uma grande chance dessa sua requisição, por exemplo, ir da sua casa até o teu provedor de internet e do teu provedor essa requisição ir até São Paulo, onde existe, por exemplo, um backbone, uma ligação/cabo Submarino, por exemplo, que vai levar esta requisição até os Estados Unidos. E mesmo dentro dos Estados Unidos podem ter conexões intermediárias até chegar ao destino final.
Então, uma requisição, ela tem todo esse processo que acontece muito rápido, mas que não é de forma direta. E uma vez o servidor final recebendo a requisição, essa requisição é então processada e devolvida para você, passando pelos servidores intermediários até chegar na sua estação de trabalho, ao teu computador.
Nesta imagem abaixo, nós podemos ver um exemplo de requisiçãopara o IP 8.8.8.8, que é um DNS do Google, e nós vemos que essa requisição ela passa por 9 passos, por 9 intermediários até chegar efetivamente no destino que é o Google. Uma vez entendido o que é uma requisição HTTP, que ela chega no servidor de destino e devolve uma resposta, é importante conhecer os principais métodos de requisição HTTP que vamos utilizar.
Métodos HTTP mais comuns
Nessas chamadas, temos uma nomenclatura que é conhecida no meio do desenvolvimento como CRUD. Que se referencia a CREATE -> CRIAR, READ -> LER, UPDATE -> ATUALIZAR, DELETE -> EXCLUIR. E para cada uma dessas ações, nós temos um método HTTP correspondente. Então, para o create, que é criar, nós temos um método POST. Para o read, que é ler, nós temos o método GET, para o update, que é atualizar, nós temos o método PUT e para o delete, que é excluir, nós temos o método DELETE.
Registrando em Anypoint Platform
Uma vez que agora nós já conhecemos como funciona uma requisição HTTP e os principais métodos HTTP que vamos utilizar, vamos efetivamente fazer o nosso registro no Anypoint Platform e vamos colocar a mão na massa. Então vamos acessar https://anypoint.mulesoft.com/login/signup e vamos fazer o nosso cadastro.
Nós temos um período de experimento de 30 dias e é importante lembrar que você pode criar quantas organizações você quiser utilizando o mesmo e-mail, ou seja, após 30 dias, quando você perder algumas funcionalidades do Anypoint Platform, você pode criar uma nova conta utilizando o mesmo e-mail.
Na página principal do Anypoint Platform, nós temos a esquerda o menu principal com todas as ferramentas que estão disponíveis na plataforma. A ferramenta pelo qual nós vamos iniciar é o Design Center, onde nós vamos começar a criar a especificação da nossa API.
Design Center – Minha primeira especificação
Então vamos clicar em Design Center, vamos clicar em CREATE NEW e vamos criar uma nova especificação de API conforme a imagem abaixo.
Vai ser necessário dar um nome a esta especificação. Vou chamar de Blog API. Uma API pode ser especificada em diferentes formatos e versões de RAML e OAS. Em nosso caso vamos utilizar RAML 1.0
Uma vez que é carregado o nosso ambiente de trabalho, nós temos:
- Área com os arquivos utilizados/criados para a especificaçGão.
- Área que permite adicionar/remover dependencias (fragmentos)
- Área onde efetivamente se escreve a especificação da API
- Área onde é apresentados opções de AUTO-COMPLETAR sempre que disponível para uso
- Visualização humanizada do código/especificação
- Mocking-Service – serviço de simulação para teste da especificação
- Área que apresenta os erros encontrados no código da especificação
Então vamos entender o que que está codificado na nossa especificação até agora. É uma especificação bem simples onde está pendente uma série de de regras, mas que é suficiente para nós começarmos a entendero funcionamento de uma especificação
- Temos o título.
- Temos a versão do rammel que a linguagem de especificação que nós estamos utilizando.
- Temos a base UR que é um endereço base que nós vamos utilizar para executar a API
- Temos a versão da API.
E temos agora, efetivamente os recursos, que poderão ser acessados e que fazem parte da nossa especificação.
Pensando em um blog, inicialmente estamos criando os recursos para gerenciar usuários (CRUD).
- GET /usuarios: lista todos os usuários
- POST /usuarios: cria um novo usuário
- GET /usuarios/{idUsuario}: recupera os dados de um usuário específico por ID
- PUT/usuarios/{idUsuario}: Atualiza dados de um usuários específico por ID
- DELETE/usuarios/{idUsuario}: Exclui um usuário específico por ID
O {idUsuario} é chamado de URI PARAMETER que é o parametro que enviamos na URL que vai fazer a chamada a este recurso, por exemplo GET http://localhost:8081/usuarios/{idUsuario}
Fizemos a especificação destes recursos e o nosso próximo passo é então publicar esta especificação no Exchange.
E então é apresentado esse diálogo. Onde nós precisamos informar qual é a versão deste ASSET, deste produto que nós estamos criando. No nosso caso, vamos colocar que há 1.0.0.
Nós podemos publicá-la como estável ou em desenvolvimento. Neste momento, nós vamos deixar ela como estável. E vamos publicar a nossa API e a nossa especificação para o Exchange.
Exchange – Compartilhando Assets (produtos)
Então já temos a nossa especificação publicada. Então, vamos ao Exchange. O Exchange nós podemos entender que é um repositório. É uma área onde tudo aquilo que nós produzimos é publicado. É uma maneira fácil de se encontrar informação e de reutilizar. Pois tudo aquilo que publicamos, tudo aquilo que produzimos, não fica guardado em lugares que outros desenvolvedores não tem acesso, não tem conhecimento que existe.
Então, outros desenvolvedores poderiam acessar o Exchange e perceber que existe uma API e uma especificação publicada de uma API para um blog, e talvez, se for o caso, fazer utilização desta API e não construir uma nova do zero para o mesmo propósito.