Em um mundo onde fazemos praticamente tudo através da internet surge a necessidade comercial dos estabelecimentos em disponiblizar seus serviços através de aplicações na web. A essas aplicações damos o nome de Web Services.

Ao falarmos desse tipo de aplicação, existe uma conexão quase embrionária com o conceito de API, o qual irei abordar de forma breve nesse artigo

O que de fato é uma API?

API é a sigla para "Application Programming Interface", ela é uma interface de comunicação entre plataformas. Podemos entender a API como um conjunto de regras e protocolos que permitem que diferentes sistemas, aplicativos e plataformas possam se comunicar e compartilhar informações entre si de maneira padronizada e organizada.

Considere o seguinte exemplo:

I)

|DB| <-----> Usuário querendo saber o saldo na sua conta

Percebe o quanto é absurdo, a ideia do usuário acessar o banco de dados sem nenhum tipo de restrição? Para evitar esses, e outros tipos de problemas, utilizamos uma aplicação interface, para permitir que o usuário se conecte de forma indireta com o banco

II)

[DB] <-----> [API] <-----> Usuário querendo saber o saldo na sua conta

Neste exemplo, a API realiza uma série de regras as quais restringem o escopo de uso do usuário no banco de dados.

Há diversas aplicações possíveis para o uso de APIs, desde a comunicação com outras APIs até acesso a outros recursos independentes.

O que é um WebService?

Um WebService é uma tecnologia utilizada para permitir a Cominicação e a Troca de Dados entre diferentes sistemas e plataformas pela Internet. Basicamente, um WebService é uma API acessível via protocolos da Web.

Quais são os principais protocolos WEB?

• SOAP (Protocolo antigo, usado no começo da Web)
• HTTP/HTTPS (Protocolo Padrão para WebServices) 
• SMTP (envio de emails)

Sabendo que o protocolo padrão para requisições Web é o HTTP/HTTPS. Portanto, iremos analisar ele com mais profundidade para compreender seu funcinamento.

HTTP

O HTTP(Hypertext Transfer Protocol) é um protocolo de comunicação utilizado para transferência de informações na Web. Ele é o protocolo PADRÃO utilizado na Internet para a transferência de dados entre um cliente (como um navegador) e um servidor.

Os recursos deste protocolo são dados através de requisições as quais chamamos de VERBOS HTTP, onde os principais são:

• GET (Pegar/Buscar) : Solicita um recurso ao servidor
• POST (Publicar)  : Adiciona um novo recurso no servidor, passando os dados através do corpo de uma requisição
• PUT (Colocar)   : Usado para enviar dados para um servidor para atualização ou criação de um recurso. O corpo da solicitação PUT contém os dados a serem atualizados ou criados.
• DELETE (Deletar)  : Remove recursos do server, ele não recebe corpo
• PATCH (Corrigir)  : Correção parcial de recurso, passando a informação a ser corrigida no corpo da requisição
• HEAD (Cabeça)   : É usado para obter informações sobre um recurso sem recuperar todo o conteúdo. É útil para verificar se um recurso existe e está disponível.

*. Por boas práticas, não devemos capturar informações de cabeçalho ou body nas requests GET e DELETE

Do que é composta uma Requisição HTTP?

• Verbo HTTP Associado
• URI (Endereço de Acesso do recurso)
• Cabeçalho (Headers)
• Body (Corpo da Request)

Certo, falamos até agora de API, Webservice e Protocolos de comunicação.. Existe algum padrão arquitetural para desenvolvimento de aplicações Web?

Sim e ele é conhecimento como REST!

Mas aí... Você me pergunta, que diabo é REST? É pra eu dormir (Eu sei.. piadinha sem graça)?

Piadinhas a parte... REST significa Representational State Transfer. O REST tem como principal característica, a adoção do protocolo HTTP como regra fundamental da arquitetura.

No entanto, existe um conjunto de boas práticas para uma aplicação REST. Dizemos que quando uma uma aplicação que segue tais práticas ela é RESTFUL. Irei falar um pouco sobre cada uma dessas boas práticas.

• Verbos HTTP: a aplicação deve utilizar os verbos HTTP (GET, POST, PUT, DELETE, PATCH, etc.) para permitir a manipulação dos recursos. Cada verbo deve ser usado de acordo com a sua semântica, ou seja, o GET deve ser usado para recuperar informações, o POST para criar recursos, o PUT para atualizar recursos, o DELETE para excluir recursos, etc. Além de seguir as exigências de cada um dos verbos HTTP, como por exemplo, não utilizar body em requisições do tipo GET.
• Recursos: a aplicação deve expor seus recursos como URI (Uniform Resource Identifiers) que podem ser acessados através dos métodos HTTP. Os recursos devem ser identificáveis ​​de forma única e ter um estado associado.
• Representações: a aplicação deve fornecer representações de recursos que possam ser facilmente manipuladas por clientes. As representações podem ser em vários formatos, como JSON, XML, texto, HTML, entre outros.
• Stateless: a aplicação deve ser stateless, o que significa que cada solicitação deve conter todas as informações necessárias para processar a solicitação. O servidor não deve armazenar informações do estado da sessão do cliente!
• Cache: a aplicação deve suportar o cache, permitindo que as respostas de recursos sejam armazenadas em cache e reutilizadas.
• Segurança: a aplicação deve implementar mecanismos de segurança para proteger os recursos de acesso não autorizado.
• Testabilidade: a aplicação deve ser testável, com testes automatizados para verificar a funcionalidade dos recursos.

Beleza, requisições HTTP nos retornam Status após serem resolvidas. Quais são os principais Status HTTP?

Podemos dividir os status HTTP em famílias:

• 1xx (informações) : Composta de códigos de status informativos que indicam que a requisição foi recebida e está sendo processada.

• 2xx (sucesso) : Indicam que a requisição foi bem-sucedida e o servidor foi capaz de processá-la.

• 200 Ok    : Request bem sucedida
• 201 Created  : Um novo recurso foi criado com sucesso (POST)
• 202 Accepted : A requisição foi recebida mas nenhuma ação foi tomada sobre ela. 
• 204 No content: Não há conteúdo para enviar para esta solicitação (DELETE)

• 3xx (redirecionamento) : Apontam a necessidade da request ser redirecionada para outra URI

• 4xx (Erro do Cliente) [USB = Usuário Super Burro!] :Essa família é composta de códigos de status que indicam que ocorreu um erro na requisição do Cliente

• 400 Bad Request  : (Num tindi oq vc falou), significa que o servidor não entendeu a requisição pois está com uma sintaxe inválida.
• 401 Unauthorized  : Tal erro indica que cliente deve se autenticar para obter a resposta solicitada.
• 403 Forbidden   : O cliente não tem direitos de acesso ao conteúdo portanto o servidor está rejeitando dar a resposta
• 404 Not Found   : O recurso não foi encontrado pelo servidor (Famoso erro do Dinossauro do Google!)

• 5xx (Erro do Servidor) : Indicam que o servidor não está bem

• 500 Internal Server Error : O servidor encontrou uma situação com a qual não sabe lidar.
• 501 Not Implemented    : O método da requisição não é suportado pelo servidor e não pode ser manipulado.
• 502 Bad Gateway      : Esta resposta de erro significa que o servidor, ao trabalhar como um gateway a fim de obter uma resposta necessária para manipular a requisição, obteve uma resposta inválida.
• 503 Service Unavailable  : O servidor não está pronto para manipular a requisição.

Bem, espero que esse artigo ajude a compreender um pouco mais sobre o Web Services. E em breve espero compartilhar mais conhecimento com vocês.

That's All Folks!