Dia 14 [dando alguns passos para trás ]— parte 2 (comunicação)

Eae?!

Demorei uma tarde toda pra entender aquele trem do post anterior [na verdade foi uma revisão… sim, em algum momento da minha vida eu vi aquilo e simplesmente ficou tudo guardado em “fita” (mainframeiros entenderão RYSOS)].

WELL…

Próximo passo é justamente começar a explorar aqueles itens da lousa:

• comunicação
• front-end
• hospedagem da aplicação (nem sei se essa expressão está correta)
• back-end
• banco de dados

Vamos falar de comunicação?

Sim, vamos! E vamos também revisar (nos próximos posts) alguns conceitos adormecidos tais como:

• Redes (protocolos)
• Comunicação de dados
• Internet
• WWW

Para isso acabei de ressuscitar um livro muito bom que usei na minha pós:

Comunicação de dados e redes de computadores — Behrouz A. Forouzan

Ele estava tão guardado que parece ter saído de um museu (mas nem é tão antigo hahah) — usarei ele junto com as pesquisas o nosso amigo google :)

Quando falamos sobre comunicação (qualquer uma), temos 4 componentes:

1. mensagem: dados a serem transmitidos
2. emissor: dispositivo que envia a mensagem
3. receptor: dispositivo que recebe a mensagem
4. meio de transmissão: caminhonpelo qual a mensagem trafega para ir só emissor para o receptor
5. protocolo: conjunto de regras que controla a comunicação. Representa um acordo entre os dispositivos que estão se comunicando. Exemplo: se o emissor fala japonês e o emissor francês, a comunicação não acontece (neste caso, o idioma é o protocolo)

Observação sobre dados: Em se tratando da representação dos dados a serem trafegados durante a comunicação, quando estão no formato texto são representados por padrões de bits. Os diferentes conjuntos padrões de bits são chamados de códigos, e o processo de representação de símbolos é chamado de codificação. E o sistema de codificação mais utilizado hoje é o Unicode.

Neste momento, o que importa é o protocolo e os padrões de comunicação, então vamos a ele.

Emissores e receptores são entidades participantes de uma comunicação em rede, porém, as entidades precisam estar de acordo com o protocolo de comunicação, que define:

• sintaxe: estrutura, formato, ordem dos dados
• semântica: significado de cada conjunto de bits, como deve ser interpretado
• timing: quando e com qual rapidez os dados devem ser enviados

Aí pensei quais são as possibilidades de protocolos para aplicações web, então pesquisei no Google:

“protocolos de rede para aplicacoes web”

E na sequência pesquisei:

“http tcp/ip”

E achei uns links bacanudos

• Comunicação e serviços (disponível em: https://fsw-ceulp.gitbooks.io/desenvolvimento-de-software-para-a-web/web/)
• O que é TCP/IP? (disponível em: https://m.tecmundo.com.br/amp/o-que-e/780-o-que-e-tcp-ip-.htm)
• Criando seu próprio servidor HTTP do zero (ou quase) — Parte I (disponível em: https://tableless.com.br/criando-seu-proprio-servidor-http-do-zero-ou-quase-parte-i/)

O protocolo TCP/IP é definido em 4 camadas: Aplicação, transporte, rede (internet) e host-rede (enlace de dados).

Imagem extraída do livro Comunicação de dados e redes de computadores — Behrouz A. Forouzan — página 43

1. Camada de aplicação: é uma combinação das “subcamadas” de aplicação, apresentação e sessão. Aplicação habilita as entidades para acessar a rede; Apresentação é responsável pela sintaxe e semântica da comunicação; Sessão controla o diálogo da rede e pela sincronização dos dados.
2. Camada de transporte: é responsável pela entrega das mensagens, processo a processo.
3. Camada de rede: responsável por garantir que cada pacote seja transmitido até o ponto final. No caso do TCP/IP, ele suporta o internetworking protocol (que usa outros protocolos de suporte)
4. Camada de enlace de dados e física: da confiabilidade á comunicação e coordena a as funções necessárias para transportar os bits através do meio físico.

O endereçamento no TCP/IP é dividido assim:

Imagem extraída do livro Comunicação de dados e redes de computadores — Behrouz A. Forouzan — página 46

• endereço físico: é o endereço de um nó (computador).
• endereço lógico: é o endereço, na internet, de 32 bits que representa o endereço físico de forma que cada host seja identificado de forma única. É o IP.
• endereço de portas: depois que o conjunto de dados trafega do host até o destino, ele precisa saber onde os dados serão entregues. Falando techinês, em qual processo (já que podem ser simultâneos) está envolvido no transporte dos dados (em que porta: endereço de 16 bits)
• endereço específico: é o endereço amigável ao usuário (URL)

Nosso amigo HTTP

Bem… lembram que na primeira figura que mostrei, temos o HTTP representado na camada de aplicação? Pois é! O famoso HyperText Transfer Protocol é um protocolo muito utilizado por sistemas WEB para estabelecer a comunicação entre “cliente e servidor”.

Como funciona a comunicação neste protocolo?

1. Cliente gera uma requisição para o servidor — representado pelo browser (que pode ser uma solicitação qualquer)
2. Servidor recebe a requisição, processa a solicitação e retorna (no gitbook Desenvolvimento de software para web, ele chama isso de solicitação e resposta).

Tá Mi, mas na prática isso funciona como?

Neste ponto, peguei o entendimento da explicação no texto “Criando seu próprio servidor HTTP do zero (ou quase) — Parte 1 do Thiguetta, no tableless (usando sempre junto com os conceitos do livro do Forouzan):

Imagine que você tem uma página web hospedada em um servidor HTTP. Essa página estará escrita em HTML (com outras coisinhas tipo um javascript, por exemplo). Quando você digitar no seu browser (que faz o intercâmbio entre você, client, com o servidor) a URL (o endereço amigável para o usuário) e der um “ENTER”, será enviada uma requisição ao servidor, que vai processar a informação e devolver o HTML (este por sua vez, ‘lido’ [renderizado] pelo browser será apresentado da forma bonitinha que estamos acostumados RYSOS).

As mensagens trocadas nas solicitações são simples e com formatos similares, sendo respectivamente:

• Solicitação: 1 linha para a solicitação, 1 para o cabeçalho e algumas vezes corpo
• Resposta: 1 linha de status , 1 de cabeçalho e algumas vezes corpo

No texto do Thiguetta tem alguns exemplos legais:

Exemplo 1: envio de solicitação (sem corpo)

GET /index.html HTTP/1.1
Host: google.com

Aqui temos:

• na linha 1: o tipo solicitação, a página que está sendo solicitada, o padrão do HTTP utilizado
• na linha 2: a referência de qual é o meu host (servidor)

Exemplo 2: recebimento da resposta (sem corpo)

HTTP/1.1 200 OK

Onde temos somente uma linha com o status da solicitação.

(O texto também tem exemplos com corpo mas achei que seria informação demais para a minha pessoa ahhahaha)

Legal Mi, vi um exemplo, mas, que tipo de solicitação é essa aí? Quais são as solicitações possíveis? E Quais são os status de retorno possíveis?

Que bom que alguém perguntou! O livro trás essas aqui ó:

Solicitações

• GET — Solicita um documento para o servidor
• HEAD — Solicita informações sobre um documento, mas não o documento em si
• POST — Envia informações do cliente para o servidor
• PUT — Envia um documento do servidor para o cliente
• TRACE — Ecoa uma solicitação que chega
• CONNECT — Reservado (sinceramente não entendi rs)
• OPTION — Solicita um detalhamento sobre as opções disponíveis

Status (retorno):

Informativo;

• 100 — Continue — A parte inicial da solicitação foi recebida e se o cliente desejar ele pode prosseguir
• 101 — Switching — O servidor está atendendo a solicitação de um cliente para alterar os protocolos definidos no cabeçalho de atualização

Sucesso;

• 200 — OK — A solicitação foi bem sucedida
• 201 — Created — Uma nova URL for criada
• 202 — Accepted — A solicitação foi aceita, mas não pode ser executada imediatamente
• 204 — No content — Conteúdo inexistente no corpo da solicitação

Redirecionamento;

• 301 — Moved permanently — A URL solicitada não está mais em uso pelo servidor
• 302 — Moved temporarily — A URL solicitada está temporariamente movida
• 304 — Not modified — O documento não foi modificado

Erros no cliente [os 4 primeiros são bem familiares pra mim RYSOS];

• 400 — Bad request — Erro de sintaxe na solicitação
• 401 — Unauthorized — A solicitação não tem autorização suficiente para ser executada
• 403 — Forbidden — Serviço negado
• 404 — Not found — O documento não foi encontrado
• 405 — Method not allowed — O comando solicitado não é suportado por esta URL
• 406 — Not acceptable — O formato solicitado não é aceitável

Erros no servidor;

• 500 — Internal server error — Há um erro como um crash, por exemplo, no servidor
• 501 — Not implemented — A ação solicitada não pode ser executada
• 503 — Service unavailable — O serviço está temporariamente indiponível mas poderá ser solicitado no futuro

Veja uma lista mais completa das mensagens de retorno aqui.

Fiquei pensando que devem haver muitos outros tipos… então pesquisei no nosso amigo google

“tipos de solicitação http”

E novamente, na sequência :

“lista de métodos HTTP”

E fui fuçar os links:

• O protocolo HTTP: Trás informações sobre o protocolo em si e uma pequena lista de solicitações, respostas e seus respectivos cabeçalhos. Bem útil!
• Como funcionam as aplicações web: Esse artigo é ótimo! Tem uma explicação detalhada de como é o fluxo desde quando o usuário clica no browser até quando ele visualiza a página. Mas os métodos são os mesmos que coloquei aqui RYSOS
• Method definitions: Nem sei como cheguei nesse link (não estava no top10 do google, mas achei interessante porque explica um pouco mais detalhadamente cada método.
• HTTP request methods: tradução do conteúdo do mozilla developers.
• Protocolo HTTP: O site do São Paulo Perl Mongers tem um detalhamento bem interessante sobre as classificações das mensagens de retorno, e tem outros exemplos de envios de requisição, mas achei melhor por enquanto não entrar nesse nível detalhe RYSOS

Achei mais só 2 método (tipo de solicitação) a mais: DELETE = Informa por meio do URL o objeto a ser deletado; PATCH = aplica modificações em um objeto.

Sobre a classificação das mensagens de retorno, os códigos tem um padrão de 3 dígitos sendo que sempre o primeiro deles indica a natureza do retorno, classificando em:

1XX: Informativa — A requisição foi recebida e o processamento continua normalmente.

2XX: Sucesso — A requisição foi recebida, processada e finalizada com sucesso.

3XX: Redirecionamento — Existe alguma ação que precisa ser tomada para processar a requisição

4XX: Erro no cliente —Houve um erro na requisição do lado do cliente

5XX: Erro no servidor — Houve um erro na requisição do lado do cliente

A lista completa de códigos de status pode ser vista aqui.

E por hoje acho que já foi muita informação RYSOS. No próximo post vamos continuar falando do HTTP, mas focando em entender melhor esse envio e recebimento de informações, como usar seus métodos, como tratá-los, e buscar exemplos de envio de solicitação pelos métodos e retornos.

Arrivederci!

Mi