No desenvolvimento de uma aplicação web,
uma das principais coisas que vamos ter é o HTTP,
ele é basicamente a base de tudo o que nós fazemos.
E veja, não estamos falando aqui só de aplicação para o navegador,
o HTTP também está embarcado em aplicações mobile
e mesmo alguns sistemas que nós pensamos que foram desenvolvidos
com a estrutura compilada.
Isso porque ele trabalha muito bem
com essa ideia de interação cliente-servidor.
Muito disso se deve aos seus métodos.
E aí podemos destacar os principais,
que são o GET, que eu obtenho informação,
o POST, que eu publico uma informação,
PUT, eu adiciono uma informação para alguém que já existe.
No caso, por exemplo, um usuário ou um campo que já está determinado.
E DELETE onde eu mando remover alguém.
Foi justamente essa estrutura
que moldou todo o mercado de TI que conhecemos hoje em dia,
principalmente nas aplicações web.
É através deles que conseguimos
enviar, receber ou alterar algum dado
nos sistemas que usamos no dia a dia.
Mas eles não estão sozinhos,
em especial porque o HTTP
normalmente tem um problema de segurança.
Esses dados estão expostos na rede,
disponíveis para qualquer hacker poder acessar.
Justamente por isso que veio o HTTPS,
onde temos a parte de segurança sendo implementada.
E é nele, por exemplo,
que ganhamos a criptografia dos dados que estamos operando.
E aqui também vamos ter que ter alguns detalhes a nos atentar.
Toda URL que esse endereço de acesso às páginas web
será composta por protocolo,
no caso HTTP ou HTTPS,
o DNS que estamos acessando,
que é o nome do domínio da página ou da aplicação que quero acessar,
e uma porta, que é um número que vai lá no final.
E se você nunca viu esse número antes,
é porque ele é subentendido em alguns casos.
Por exemplo, o HTTP utiliza a porta 80,
o HTTPS utiliza a porta 443.
Mas caso desenvolva, por exemplo,
um front-end ou um dashboard de API,
é normal o colocarmos lá na porta 5000,
e aí eu preciso especificar esse endereço.
Se nós acessarmos, por exemplo, o site do Google,
já podemos ver como é que ele vai funcionar.
Notem que já temos aqui o nosso protocolo HTTPS,
indicando que é só uma conexão segura.
Mas veja, não é porque eu tenho um HTTPS aqui
que eu estou 100% seguro.
Na realidade, isso só diz que eu tenho um certificado em uso,
não necessariamente que esse é o certificado do Google,
já já nós vamos ver como é que validamos isso.
Na sequência, nós temos o endereço DNS do Google
e aqui está subtendido a porta 443.
"Professor, como é que conseguimos ver todos esses detalhes?"
Se clicarmos aqui em cima do ícone do Google
ou clicar em cima do cadeado que aparece
quando temos aqui o HTTPS,
nós conseguimos ver as informações desse site.
Por exemplo, ele está indicando que essa conexão é segura,
se eu clico para pedir mais informações,
ele me traz um briefing e me traz um acesso ao certificado.
Onde eu consigo checar, por exemplo,
quem foi que emitiu esse certificado.
No caso, esse certificado foi emitido para o Google
por uma companhia chamada "GTS CA 1C3",
que, no caso, é o próprio serviço de segurança da Google.
Também conseguimos ver a data de emissão
e os hashs de uso desse certificado,
como, por exemplo, a chave pública.
Isso porque toda comunicação HTTPS
funciona baseada em chave pública e privada.
A chave pública nós vamos utilizar
para assinar qualquer dado
que eu queira mandar para o servidor,
afinal, só a chave privada vai abrir esse dado.
Já quando eu assino com a chave privada,
a pública consegue abrir,
e isso não é tão interessante quando eu quero garantir segurança.
"Professor, e aí, como é que eu faço?"
Normalmente, quando eu chamo esse site,
nós já negociamos ali, utilizando as chaves públicas,
um acordo de senha para usarmos
ou um outro certificado privado para nós usarmos.
E dessa forma nós escapamos desse problema
de assinar com a chave privada e ler com a chave pública.
Outro detalhe importante é que temos mais algumas informações
e detalhes sobre esse certificado.
Mas voltando aqui no cadeado,
vejam que também terá algumas opções,
como os cookies que estão em uso
ou mesmo, as informações sobre os trackings,
que são os acessos que estamos pedindo.
Os trackings vão ser referentes
a basicamente qualquer coisa que queiramos acessar,
desde a localização
ou até a possibilidade de armazenar algum dado no computador.
Só que o cookie é um pouquinho mais delicado.
O cookie teoricamente são dados
que nós estamos salvando nessa máquina
para acelerar a nossa página.
Ele é uma espécie de client-side
ou processamento do lado cliente.
Onde conseguimos aliviar o tráfego do servidor,
só que expondo ao risco
de ter parte do meu código
disponível na máquina do usuário.
Além disso, o cookie também salva
vários outros componentes da página,
como fotos muito acessadas, logomarcas e coisas do gênero.
Então, ele termina sendo usado,
o problema é qual dado eu estou passando para ele.
Já quando falamos do server-side,
ele vai compor todos os dados que nós temos do lado do servidor
e aí nós terminamos tendo um pouco mais de segurança.
Eu vou me preocupar muito com o ataque
que vai tentar explorar,
mas isso tudo vai vir via rede
e não simplesmente eu disponibilizar esse código aberto para todo mundo.
Além disso, essa nossa interação nem sempre é bem sucedida
e justamente por isso o HTTP tem códigos.
Toda vez que você recebe um código 200, por exemplo,
é porque a sua solicitação deu certo,
toda a família 200 quer dizer solicitação bem sucedida.
Já quando nós falamos da família 500,
nós estamos falando da família dos erros.
O famoso erro 404 já está em outra família
para indicar falha no server-side,
onde eu não consegui achar o endereço.
Então, cada código vai ter ali a sua família
e, dentro dessas famílias, os erros que ele está justificando.
Veja que só para manter uma aplicação web no ar
já temos que ter uma série de cuidados
e trabalhar minunciosamente vários pontos.
Mas são justamente esses pequenos pontos
que me permitem arquitetar uma solução web
que vai ser ao mesmo tempo útil e segura.