Aula 01 - Serviços Web
Visão geral da implementação de serviços web
Serviços Web

Um Web Service, ou simplesmente Serviço Web, é normalmente um software/dispositivo que tem como objetivo prover dados para outras aplicações através do protocolo http/https. Isso significa que ao invés de fornecer recursos à usuários finais, cujo a informação tem fim em si mesma, os usuários de serviços web são normalmente outras aplicações, construídas para enviar e receber dados através desses serviços.
Um serviço web pode ser construído, por exemplo, para funcionar como uma camada intermediária entre os dados armazenados e uma interface web, sendo responsável pelo tratamento e entrega dos dados a serem apresentados. Como exemplo, podemos citar outras utilizações para um webservice:
- Ler os dados de sensores e fornecer esses dados para um aplicativo mobile através da Internet;
- Verificar e fornecer um serviço de autenticação para múltiplicas aplicações dentro da rede de uma empresa;
- Enviar mensagens através de um BOT para mensageiros instantâneos;
- Receber fotos de uma aplicação desktop através da Internet, armazenando-as de modo seguro.
Um web service é geralmente considerado um tipo de API (Application Programming Interface - Interface de programação de aplicações), já que oferece um ponto de interface capaz de interagir com uma aplicação/código externo.
Atualmente podemos encontrar milhares de API disponíveis de maneira pública na Internet. Alguns exemplos:
Algumas APIs requerem autenticação. Isso significa que para realizar requisições é necessário ter algum tipo de cadastro realizado previamente. Também
TCP e IP

Estes dois protocolos de camadas mais inferiores são geralmente utilizados como base para a troca de informações na web. Enquanto o protocolo IP (Camada Internet) provê o roteamento da mensagem através dos servidores, fazendo com que os pacotes cheguem ao destino correto, o protocolo TCP (Camada Transporte) garante a integridade e a entrega de todos os pacotes. Tipicamente, requisições que chegam nessa camada acima do MTU (Maximum Transmission Unit) são divididos em vários pacotes a serem entregues.
DNS

Todo dispositivo presente em uma rede de computadores da família TCP/IP é identificado virtualmente através de um endereço IP. Esse endereço é adequado para os computadores, porém de difícil memorização para seres humanos. Por isso, cada endereço IP pode ter um ou mais nomes de domínio atrelados que facilitam sua identificação e a organização dos serviços na web.
Quando acessamos um webservice através de um nome de domínio (exemplo.com.br), é necessário obter antes o endereço de IP do servidor que irá realizar a resposta da requisição. Esse processo também é conhecido como forward lookup.
Nesse processo, o cliente realiza um requisição para o servidor de DNS local (geralmente configurado na máquina ou pelo provedor de internet). Se este servidor DNS não possuir a informação do endereço IP correspondente aquele domínio, ele informa o endereço de outro servidor (geralmente um servidor mais próximo da raiz) onde aquele endereço poderá ser encontrado. Este mesmo servidor volta a realizar uma requisição (DNS Query) até que o endereço de IP referente àquele servidor seja encontrado.
Geralmente os nomes de domínio são gerenciados por agências locais (como o NIC.br no Brasil) que padronizam, definem e comercializam os nomes de domínio. Uma outra característica importante do DNS é que os nomes são organizados de maneira hierárquica, ou seja, a cada ponto temos um agrupamento de domínios que geralmente possuem um representante centralizado. Por exemplo, no domínio professor.venson.net.br, possuimos a seguinte hierarquia:
.br- TLD (Top-Level Domain). Delegado pela IANA, administrado pelo NIC.br e comercializado no site registro.br.net.br- Subdivisão do domínio brasileiro. Responsabilidade do NIC.brvenson.net.br- Nome de domínio registrado para uma pessoa física / júridica (whois)professor.venson.net.br- Subdivisão do domínio registrado. Administrado e configurado pelo dono do domínio.
Mais informações aqui
HTTP

O Hypertext Transfer Protocol é um protocolo do tipo ou requisição/resposta. É um protocolo sem estado, o que significa que ele não pode identificar relação entre duas requisições distintas. Isso pode ser um grande problema quando trabalhamos com aplicações que exigem, por exemplo, algum tipo de autenticação. Nesses casos, é necessário que o controle de sessão seja feito pela aplicação que usa o protocolo. Uma mensagem HTTP é geralmente composto por três partes:
- Linha de requisição, onde especificamos três parâmetros:
METHOD, que define a ação da requisição (por exemplo,GETsignifica que queremos obter algum dado/recurso);HEADER, que define um dicionário contendo informações que serão de interesse de quem interpretará a mensagem (como por exemplo,User-Agentidentifica o cliente/navegador usado na requisição);BODY, o corpo da mensagem que pode conter strings especiais, texto plano, JSON, binários, etc. Esta parte da mensagem é geralmente apenas de interesse da aplicação. No caso de um website, o código-fonte da página é entregue dentro dessa área.
Por padrão, a transferência de mensagens do HTTP é realizada na porta 80, definida no protocolo TCP. É necessário, também, que a conexão com o servidor seja estabelecida de maneira previa ao envio da requisição HTTP, já que de fato é um protocolo que se encontra na camada de aplicação do modelo OSI.
Realizando conexões
Sempre que uma requisição HTTP é feita, é preciso que as camadas de rede/transporte realizem a conexão com o servidor antes de realizar qualquer requisição.
Em servidores configurados para tal, é possível especificar o cabeçalho Connection: Keep-Alive para garantir que a conexão TCP/IP não será encerrada pelo servidor após a resposta, garantindo assim que a conexão possa ser reutilizada para múltiplas requisições.
Isso
HTTPS
Mantendo suas principais características em relação à mensagem, o HTTPS se difere do HTTP por realizar a encriptação da mensagem HTTP antes da transmissão, descriptografando a mensagem após a sua chegada. Essa camada de segurança é conhecida como Transport Layer Security, ou TSL. As transações do TLS são negociadas usando um par de chaves públicas/privadas. A porta padrão utilizada pelo HTTPS é a 443.
O TSL é uma versão mais recente do Secure Sockets Layer (SSL), que também é usada para descrever a mesma camada. No entanto, é comum encontrar o termo SSL ou SSL/TLS que também possui o mesmo significado.

Desde suas primeiras versões, o protocolo HTTP recebeu uma grande quantidade de novas funcionalidades que ajudaram a aprimorar sua utilização:
1.0(1996)- Pouco/Nenhum suporte a compressão
- Apenas
GET,HEADePOST
1.1(1997)- Novos Métodos e Códigos de Resposta
- Keep-Alive
- Compressão aprimorada do corpo da mensagem
2.0(2015)- Compressão do cabeçalho
- Resposta e Requisições Multiplexada na camada de aplicação. Permite "enfileirar" requisições e respostas. Pacotes perdidos na camada de rede/transporte ainda bloqueiam as requisições
- Server-Push (servidor envia respostas sem necessidade de requisições)
3.0(2018)- Troca do TCP+TLS para UDP+QUIC
- Multiplexação não bloqueante na camada de transporte. Pacotes perdidos na camada de rede/transporte não bloqueiam outros pacotes
A troca de mensagens através da Web permite criar requisições/respostas com diferentes tipos de conteúdo (que são carregados pelo corpo da mensagem). Podemos utilizar qualquer tipo de codificação, que geralmente é informada no cabeçalho da mensagem usando a propriedade Content-Type e o tipo MIME. Esses tipos podem ser listados abaixo (mas não se resumem a estes):
- Texto plano genérico (
text/plain). Mensagens enviadas em texto plano exigem apenas conhecer a codificação de caracteres para sua interpretação. Por padrão, a codificação mais utilizada na web é aUTF-8(fonte 1, fonte 2). - Áudio (
audio/mpeg). Inclui dados de áudio ou música, no formato especificado - Vídeo (
video/mp4). Inclui dados de vídeo, no formato especificado - Imagem (
image/png). Inclui dados de imagem, no formato especificado - Binário (
application/octet-stream). Conteúdo em formato binário, sem uma codificação conhecida - PDF (
application/pdf). Conteúdo em formato pdf - HTML (
text/html). Conteúdo html, em forma de texto plano - Formulário (
multipart/form-data). Conteúdo de um formulário HTML - JSON (
application/json). Um arquivo de dados estruturado JSON
Mais sobre aqui
Construindo um Web Service

O JavaScript é uma linguagem de programação dinâmica que foi criada por BrendanEich, também co-fundador do projeto Mozilla.
A flexibilidade do JavaScript permitiu que ele fosse utilizado em diversos ambientes,que vão muito além da interação dinâmica com páginas HTML, pro qual foi criado.
Atualmente, o JavaScript pode ser utilizado para construir aplicações para diversosdispositivos (deskop, mobile, web...) e diversos ecosistemas.
O JavaScript é padronizado pela ECMA International, uma organização parapadronização de sistemas de comunicação. Essa padronização é publicada através deespecificações, que por sua vez são utilizadas por empresas e projetos para projetarsuas próprias implementações do javascript.

O Node.js é um interpretador de código javascript focado na criação de aplicações assíncronas de alta escalabilidade no lado de servidores.
Site do Node.js

O express é um framework utilizado em aplicações Node.js de carater minimalista que tem como objetivo oferecer um conjunto de recursos para o desenvolvimento de aplicações para a web em geral.
O framework express pode ser utilizado para construir desde servidores web com páginas estáticas até APIs (Application Programming Interfaces), oferecendo backend para outras aplicações.
O express.js pode ser instalado através de gerenciador de pacotes (como o NPM).
Site do Express.js

O MongoDB é software multi-plataforma de base de dados orientado a documentos e ao modelo JSON. Sua primeira versão foi públicada em 2009.
Suas características permitem a criação de dados aninhados em hierarquias complexas e flexíveis, mas que ainda permitem a indexação e busca eficiente.
O MongoDB pode ser instalado em sua versão Comunity ou utilizado diretamente através da nuvem da Atlas.
Site do MongoDB Community Edition
Site da Atlas

A Web que conhecemos é recheada de recursos. Estes recursos podem ser entendidos como basicamente qualquer coisa que possa ser identificada e endereçada. Dessa forma, é muito comum atualmente que os dados que acessamos ao navegar pela Web possuam uma estrutura sólida que permita que diferentes serviços possam se comunicar usando um padrão comum.
Uma das arquiteturas mais utilizadas na web para criação de APIs que permitem a troca informações entre serviços é o padrão REST (Representational State Transfer). Essa arquitetura define um conjunto de restrições na representação e operação de dados que são utilizadas na criação de serviços web.
REST é um acrônimo para Representational StateTransfer.
Site com documentação para o REST
O JSON (Javascript Object Notation) é um formato de troca de dados em modo texto baseado na notação de objetos do javascript. Ele é utilizado atualmente em muitas APIs na Web para fornecer e receber dados em um formato padronizado e de fácil desconstrução.
- Significa Java Script ObjectNotation;
- É um formato para troca de dados;
- Independente de linguagem de programação;
- Sintaxe simples e textual;
{
"usuarios": {
"john": {
"email": "john@matrix.com",
"senha": "12345"
},
"mary": {
"email": "m.mary@bol.com.br",
"senha": "abc123",
"admin": true
}
}
}
Mão na Massa
Usando esta lista de APIs públicas como referência, pesquise uma API pública que seja capaz de retornar dados através da web e descreva, em um arquivo de texto, as seguintes propriedades:
- Endereço da API
- Descrição de que tipo de dados são retornados
- Mantenedor/Desenvolvedor da API
- Protocolo usado (HTTP ou HTTPS)
- Qual o tipo de conteúdo retornado (
Content-Type) - Qual o método HTTP usado e seu código
- Um exemplo de conteúdo (corpo) retornado
Exercícios Complementares
Usando esta lista de APIs públicas como referência, pesquise uma API pública e crie um algoritmo que seja capaz de gerar uma requisição para esta API, imprimindo os dados no console e/ou armazenando-os em um arquivo de texto.
Lembre-se que para realizar uma requisição através do navegador, é necessário que a API possua no cabeçalho de suas requisições a propriedade Access-Control-Allow-Origin: *