Vamos conhecer os principais conceitos sobre a Internet e o Protocolo HTTP
Antes de falarmos sobre a Internet, precisamos compreender o conceito de Rede de Computadores.
Uma Rede de computadores é um conjunto de equipamentos interligados de maneira a se comunicarem, trocarem informações e compartilharem recursos, como arquivos de dados gravados, impressoras, modems, softwares e outros equipamentos.
Quando falamos em Redes de Computadores, um outro conceito fundamental, que não pode ser ignorado é a Comunicação de dados, que é a troca de informação entre dois dispositivos através de algum meio de comunicação como, por exemplo, um par de fios:
Um sistema básico de comunicação de dados é composto por cinco elementos:
- Mensagem: é a informação a ser transmitida;
- Transmissor: é o dispositivo que envia a mensagem de dados;
- Receptor: é o dispositivo que recebe a mensagem;
- Meio: é o caminho físico por onde viaja uma mensagem dirigida ao receptor;
- Protocolo: é um conjunto de regras que governa a comunicação de dados. Ele representa um acordo entre os dispositivos que se comunicam.
Estes 5 elementos são a base de qualquer Rede de Computadores.
A Internet é a Rede Global de Computadores (incluindo PC's, Notebooks, Tablets, Celulares e outros equipamentos que acessam a rede) interconectados. A Internet permite a troca de informações, serviços e recursos entre dispositivos em todo o mundo. Imagine um grande sistema de Correios, que entrega e recebe pacotes contendo informações em velocidades extremamente rápidas. Em linhas gerais é assim que a Internet funciona.
Para manter o recebimento, despacho e entrega destes pacotes pela grande rede, a Internet utiliza dois Protocolos essenciais: TCP (Transmission Control Protocol) e o IP (Internet Protocol). O TCP/IP surgiu da necessidade de se padronizar a Internet, estabelecendo padrões universais, que permitem o seu uso em qualquer parte do mundo. Sem estes protocolos, a Internet como conhecemos e utilizamos hoje, simplesmente não existiria.
O TCP/IP é um conjunto de protocolos de comunicação. O nome vem dos dois protocolos citados anteriormente:
- Protocolo de Controle de Transmissão (TCP): Responsável pela transmissão confiável de dados. Ele divide as informações em pacotes, garante que eles cheguem corretamente e reordena-os, se necessário.
- Protocolo de Internet (IP): Identifica computadores e servidores na rede. Cada dispositivo conectado à Internet possui um endereço IP exclusivo.
Além dos 2 protocolos citados acima, existem mais alguns outros, que veremos a seguir. Todos estes protocolos, trabalhando em conjunto, padronizam todas as comunicações comunicações na Internet. A Pilha de Protocolos TCP/IP literalmente definem a Internet.
A Imagem abaixo, faz um resumo da Pilha de Protocolos TCP/IP:
Como vemos na imagem acima, o modelo TCP/IP é composto por 5 camadas:
Nesta camada encontra-se todos os protocolos de serviço, que efetuam a comunicação direta com os softwares do cliente ou do servidor, para identificar qual aplicação está enviando a Requisição que está sendo realizada. Ela inclui protocolos como HTTP (para páginas da web), SMTP (para e-mails) e FTP (para transferência de arquivos).
Esta camada é Responsável pela comunicação entre os Clientes e os Servidores. Ela tem como função principal verificar se o pacote de dados alcançou seu destino e se os dados nele contidos chegaram de maneira integra.
Nesta camada operam 2 protocolos:
- O TCP (Transmission Control Protocol), que garante a entrega confiável dos dados. O TCP é utilizado em qualquer tipo de comunicação onde a entrega dos pacotes deve ser controlada de forma rígida, como por exemplo, cadastros e transações bancárias.
- O UDP (User Datagram Protocol), que embora seja mais rápido, não garante a entrega dos dados. O UDP é muito utilizado em Streaming de audio e/ou vídeo e Voz sobre IP, que não necessitam de um controle de recebimento de pacotes tão rígido.
Pacote é o formato no qual os dados são enviados do servidor para o cliente e vice e versa. Basicamente, quando os dados são enviados pela web, eles são enviados como milhares de pequenos blocos, para agilizar e simplificar o tráfico de dados pela Internet.
Observe na imagem acima, que em azul temos o grande bloco de dados e logo abaixo, na cor amarela, o mesmo bloco dividido em pacotes menores, que serão identificados e enviados um a uma para o seu destino.
Se a entrega de pacotes estiver usando o protocolo TCP, ao chegar no destino, ele se encarregará de checar se todos os pacotes chegaram. Caso um ou mais pacotes não tenham chegado no destino, a origem será comunicada e ela enviará todos os pacotes novamente, quantas vezes forem necessárias, até que o destino confirme o recebimento de todos. O TCP age desta forma, porque numa transação bancária, por exemplo, se um pacote não chegou, ele pode representar alguns zeros a menos na conta bancária do cliente, o que causaria muitos transtornos.
Se a entrega de pacotes estiver usando o protocolo UDP, essa checagem não será realizada no destino. Em outras palavras, se o pacote chegou, chegou! Se não chegou, pouco importa. O protocolo UDP age desta forma, porque no caso de um Streaming de vídeo, por exemplo, se um pacote não chegou, os demais pacotes conseguem reproduzir o vídeo sem maiores perdas para quem assiste. Além disso, imagine você estar assistindo um filme e de repente o TCP emite a mensagem: "Estamos aguardando chegar um pacote para continuar a reprodução do filme!". Com certeza a experiência com o serviço de Streaming não seria boa!
Resumindo:
TCP 🡪 Controle total sobre a entrega de pacotes
UDP 🡪 Nenhum controle sobre a entrega de pacotes
A camada de transporte utiliza portas lógicas para garantir que a aplicação que iniciou a conversação encontrará no seu destino a aplicação desejada. Essas portas lógicas são canais virtuais, geralmente definidos pelo Sistema Operacional, que se abrem conforme o tipo de aplicação que se está executando.
Alguns exemplos de portas:
- O Protocolo HTTP utiliza na Internet a porta 80 como porta universal.
- O Protocolo HTTPS utiliza na Internet a porta 443 como porta universal.
- O Spring utiliza localmente a porta 8080.
- O Nest, utiliza localmente as portas 3000 ou 4000.
- O ASP.NET utiliza localmente a porta 5000.
Nesta camada encontramos o Protocolo IP, responsável por definir os endereços IP de origem e destino de uma conexão. O Protocolo IP roteia os pacotes entre dispositivos usando endereços IP. O endereço IP é como se fosse o endereço de origem e destino de uma carta ou encomenda entregue pelo Correio. O IP também é conhecido como Endereço lógico (endereço que pode ser alterado).
Nesta camada encontramos a conexão entre a parte lógica e a parte física da rede pela qual o pacote trafega. Cada equipamento conectado na rede carrega consigo a identidade do hardware que deu origem ao envio do pacote, armazenando o seu endereço MAC (Media Access Control). O MAC também é conhecido como Endereço físico (não pode ser alterado, exceto se a placa de rede for trocada).
Nesta camada encontramos o protocolo ARP (Address Resolution Protocol), que é utilizado para mapear os endereços IP (lógicos), que operam na camada 3, para os endereços MAC (físicos), que operam na camada 2.
A camada física envia e recebe os bits de dados brutos sobre o meio físico, como cabos metálicos (via pulsos elétricos), cabos óticos (via feixes de luz) ou Wireless (via ondas).
Para entender como funciona a transmissão de dados via Internet, assista o vídeo Warriors of the NET - IP for Peace, no link abaixo.
O HTTP (Hypertext Transfer Protocol / Protocolo de Transferência de Hipertexto) é o protocolo que permite a obtenção de recursos, como documentos HTML. É a base de qualquer troca de dados na Web e um protocolo cliente-servidor, o que significa que as requisições são iniciadas pelo destinatário, geralmente um navegador da Web. Um documento completo é reconstruído a partir dos diferentes sub documentos obtidos, como por exemplo texto, descrição do layout, imagens, vídeos, scripts e muito mais.
Observe na imagem acima, que uma página web é composta por diversos elementos, com origens variadas.
O HTTP também possui uma outra versão chamada de HTTPS ( Hyper Text Transfer Protocol Secure / Protocolo de Transferência de Hipertexto Seguro), que se trata de uma versão do protocolo criptografado, geralmente utilizado em transações bancárias. Ao utilizar o protocolo HTTPS, um cadeado 
O Protocolo HTTP utiliza como modelo base de comunicação o Modelo Cliente - Servidor (Client-Server), como vemos na imagem abaixo:
O Cliente é qualquer ferramenta que age em nome do usuário. Essa função é predominantemente realizada pelo navegador Web, salvo algumas poucas exceções, são programas usados por pessoas Desenvolvedoras Web para testar as suas aplicações, como Insomnia e o Postman.
O servidor é a "máquina" que serve o documento requisitado pelo usuário através do endereço www. Um servidor se apresenta virtualmente apenas como uma máquina, porém ele pode ser uma coleção de servidores dividindo a carga ou um programa complexo que acessa outros servidores gerando toda ou parte do documento solicitado.
O HTTP funciona como um protocolo Request-Response (Requisição-Resposta), entre um Cliente e um Servidor. Na imagem abaixo, vemos o fluxo básico do protocolo HTTP:
Exemplo: Um cliente (Navegador da Internet) envia uma Requisição HTTP ao servidor e o servidor retorna uma Resposta ao cliente.
Para o cliente se comunicar com um servidor, ele realiza os seguintes passos:
- Abre uma conexão TCP, que será usada para enviar uma requisição, ou várias, e receber as respectivas respostas.
- Envia uma mensagem HTTP (Request).
- Lê a resposta do servidor (Response).
- Fecha ou reutiliza a conexão para enviar novas requisições.
Na imagem abaixo vemos um exemplo básico de uma Requisição HTTP:
As requisições consistem dos seguintes elementos:
- O Método HTTP indica um dos verbos do protocolo http, como: GET, POST, DELETE e PUT.
- O caminho do recurso (Path), ou seja a URN do recurso, que identifica o nome do recurso e os parâmetros.
- A Versão identifica a Versão do protocolo HTTP (1.0 ou 1.1).
- O Cabeçalho (opcionais) é utilizado para inserir informações adicionais para os servidores, como o token de segurança, por exemplo.
- Body (corpo), é utilizado pelos Métodos POST e PUT, para enviar os dados que serão persistidos no banco de dados ou utilizados pelo recurso solicitado dentro da requisição.
Na imagem abaixo, vemos um exemplo mais detalhado de uma Requisição HTTP:
O protocolo HTTP define um conjunto de Métodos de requisição responsáveis por indicar a ação a ser executada para um dado recurso. Estes Métodos são referenciados como Verbos HTTP.
Principais Verbos HTTP
| Verbo | Descrição |
| GET | O Método GET solicita a representação de um recurso específico. Requisições utilizando o Método GET devem retornar apenas dados. Exemplo: Consultar um registro no Banco de Dados. |
| POST | O Método POST é utilizado para submeter uma entidade a um recurso específico para o servidor. Exemplo: Inserir um novo registro no Banco de Dados. |
| PUT | O Método PUT substitui todas as atuais representações do recurso de destino pela carga de dados da requisição. Exemplo: Atualizar os Atributos de um registro no Banco de Dados. |
| DELETE | O Método DELETE remove um recurso específico. Exemplo: Apagar um registro no Banco de Dados. |
Quando acessamos um determinado site a partir do nosso computador, informamos para o navegador o endereço do servidor, também conhecido como URL (Uniform Resource Locator). O Navegador da Internet se encarrega de descobrir qual o endereço do servidor que armazena o site.
A comunicação com uma aplicação WEB é realizada através da URI (Uniform Resource Identifier), que se trata de um identificador de recurso, composto pela URL e pelo URN (Universal Resource Name), que identifica o nome do recurso que receberá a requisição. O URN é composto pelo caminho do Recurso (também chamados de endpoints) e opcionalmente pelos Parâmetros.
Tip
Embora o nome correto seja URI (URL + URN), a maioria das pessoas desenvolvedoras e até mesmo alguns aplicativos de teste de aplicações WEB, costumam utilizar o termo URL, para se referenciar ao endereço do recurso, por ser um acrônimo mais popular.
Veja os Exemplos abaixo:
Requisição Local (seu computador)
Requisição Remota (servidor na Nuvem)
| Item | Descrição |
|---|---|
| Protocolo | Informa ao navegador qual o protocolo de comunicação do endereço (http ou https). Observe que na nuvem, utiliza-se o protocolo https, enquanto localmente utiliza-se o protocolo http. |
| Domínio | É o nome (identificador) do site. Este item é Obrigatório. Observe que localmente o seu computador é identificado como localhost, enquanto na Nuvem o endereço vai depender do nome da sua aplicação e do endereço gerado pelo serviço de hospedagem. |
| Porta | Identifica a porta em que o site está disponível no servidor. Quando não é informada o Navegador preenche internamente com a porta padrão de acordo com o protocolo utilizado. Observe que localmente, a porta deve ser informada e porta padrão do Servidor WEB local (no exemplo acima, porta 8080). No Nest vamos utilizar a porta 4000 e no ASP.NET a porta 5000. Enquanto na Nuvem, mesmo sem informar o numero da porta, por se tratar do protocolo https utiliza-se a porta padrão 443. |
| Recurso | Identifica qual o recurso o navegador vai buscar no servidor, quando não é informado pelo usuário o próprio navegador preenche com uma "/", que significa página inicial do site (index). No contexto de uma aplicação WEB, um recurso geralmente representa uma das operações do CRUD (Create, Read, Update e Delete) de uma tabela específica do Banco de dados, desenvolvido em uma Linguagem Backend. No exemplo acima, localmente está sendo procurado o recurso Postagens enquanto na Nuvem está sendo procurado o recurso Temas. |
| Parâmetros | Utilizado para enviar dados para a aplicação através do endereço. No exemplo Local, 12345 é o valor do id (identificador único) de uma Postagem que está sendo procurada. No exemplo na Nuvem, java é a palavra que está sendo procurada no campo (Atributo) descricao, de um Tema. |
Warning
Na construção da Requisição http, no item Path, não é enviado o endereço completo (URI). É enviado apenas o caminho do Recurso e os Parâmetros (URN). A URL é enviada no parâmetro Host.
Important
Os conceitos apresentados na formação da URL, em especial Recurso e Parâmetros serão estudados com mais detalhes no decorrer do Bloco 02. O mais importante neste momento é compreender quais são as partes que compõem a URL.
A Response (Resposta) é a resposta que o servidor envia ao cliente depois de processar a Requisição. Essa resposta pode conter os dados que realmente o cliente esperava receber ou uma resposta informando que alguma coisa deu errado. Na imagem abaixo, vemos um exemplo de uma Resposta do Servidor:
O protocolo HTTP também define um conjunto de **Códigos de Status de Respostas** responsáveis por indicar se a ação executada para um dado recurso foi executada corretamente ou não. Estes Métodos são comumente referenciados como **HTTP Status Code**. As respostas são agrupadas em cinco Classes:- Respostas de Informação (100 - 199): Indica que a requisição foi recebida e entendida. Essa resposta é despachada provisoriamente, enquanto o processamento da requisição continua. Serve para alertar ao cliente que espere pela resposta final. Status Code da categoria 100 são raramente utilizados.
- Respostas de sucesso (200 - 299): Indica que a ação solicitada pelo cliente foi recebida, compreendida, aceita e processada com êxito.
- Redirecionamentos (300 - 399): O cliente deve tomar medidas adicionais para completar o pedido, ou seja, indica que a ação ainda precisa ser redirecionada pelo agente de usuário, a fim de atender à requisição. Status Code da categoria 300 são raramente utilizados.
- Erros do cliente (400 - 499): Indica que o cliente parece ter cometido um erro ou enviou uma informação inválida ou incorreta. Exemplo: o usuário digitou um id inválido.
- Erros do servidor (500 - 599): Indica um erro do servidor ao processar a solicitação. Na grande maioria dos casos, está relacionada às permissões dos arquivos ou pastas do software ou script que o usuário tenta acessar e não foram configuradas no momento da programação/construção do site ou da aplicação. Também podem indicar erros no código da aplicação.
| Código | Resposta | Descrição |
| 200 | OK | Estas requisição foi bem sucedida. O significado do sucesso varia de acordo com o Método HTTP. |
| 201 | CREATED | A requisição foi bem sucedida e um novo recurso foi criado como resultado. Esta é uma típica resposta enviada após uma requisição POST. |
| 204 | NO CONTENT | Não há conteúdo para enviar para esta solicitação, mas os cabeçalhos podem ser úteis. O user-agent pode atualizar seus cabeçalhos em cache para este recurso com os novos. Essa resposta é muito comum após uma Requisição DELETE. |
| Código | Resposta | Descrição |
| 400 | BAD REQUEST | Essa resposta significa que o servidor não entendeu a requisição pois está com uma sintaxe inválida. |
| 401 | UNAUTHORIZED | Embora o padrão HTTP especifique "unauthorized", semanticamente, essa resposta significa "unauthenticated". Ou seja, o cliente deve se autenticar para obter a resposta solicitada. Esta resposta é muito comum quando habilitamos a Segurança na API (Login, Senha e Token). |
| 403 | FORBIDDEN | O cliente não tem direitos de acesso ao conteúdo portanto o servidor está rejeitando dar a resposta. Diferente do código 401, aqui a identidade do cliente é conhecida. |
| 404 | NOT FOUND | O servidor não pode encontrar o recurso solicitado. Este código de resposta acontece com frequência na web. |
| 405 | METHOD NOT ALLOWED | O servidor não pode encontrar o Método solicitado. |
| Código | Resposta | Descrição |
| 500 | INTERNAL SERVER ERROR | O servidor encontrou uma situação com a qual não sabe lidar. |
| 501 | NOT IMPLEMETED | O Método da requisição não é suportado pelo servidor e não pode ser manipulado. |
| 502 | BAD GATEWAY | 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 a requisição. Causas comuns são um servidor em manutenção ou sobrecarregado. |
Um Web Site é uma coleção de páginas da web e conteúdo relacionado que é identificado por um nome de domínio comum e publicado em pelo menos um servidor da web.
Um aplicativo da web é um software aplicativo executado em um servidor da web, ao contrário dos programas de software baseados em computador que são executados localmente no sistema operacional (SO) do dispositivo.
Apesar de mais abstrato, o conceito de Backend também é simples de entender: os dados publicados em uma rede social, como fotos e vídeos, por meio da interface do usuário precisam ser armazenados em algum local para poderem ser acessados posteriormente.
Esse envio não é feito diretamente do front-end para o banco de dados da rede social. Ao invés disso, existe uma parte da aplicação que é responsável por receber essas informações, fazer operações específicas — postagens, filtros, exclusões, verificações de segurança e validações e somente após isso, armazenar no banco de dados. Esse é o backend.
As atribuições de um desenvolvedor backend não incluem a criação de páginas bonitas ou responsivas, como acontece com profissionais frontend. Em vez disso, eles são responsáveis por implementar arquiteturas robustas, que se comuniquem com o banco de dados (MySQL) e que garantam a segurança dos dados enviados pelo usuário. Para isso utiliza linguagens como o Java e o Framework Spring.
O Frontend é, de forma sucinta, toda parte visual de um site, a parte com a qual o usuário interage diretamente. O profissional responsável por trabalhar nessa área de um projeto desenvolve o código para a interface gráfica, normalmente por meio de linguagens.
Um desenvolvedor frontend normalmente trabalha criando toda a parte visual dos sites por meio de linguagens de marcação(HTML), estilização (CSS) e programação (JavaScript e TypeScript), além de Bibliotecas como o React e frameworks como o Angular.
No exemplo acima, temos uma visão geral da integração entre o Frontend e do Backend da aplicação.
Full Stack está relacionado a pessoa desenvolvedora. Espera-se de uma pessoa desenvolvedora Full Stack que ela seja capacitada para lidar, ao mesmo tempo, com o Fron-end e o Backend de uma aplicação, mesmo que os dois lados utilizem tecnologias e linguagens diferentes.

















