vimeo.com/.../929617616

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 esses caras
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ível 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 se atentar

toda URL que esse endereço
de acesso às páginas web

será composta
por protocolo

no caso HTTP,
o HTTPS,

o DNS que
estamos acessando,

que é o nome do domínio da página
ou da aplicação que eu 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 colocarmos esse cara
lá na porta 5000,

e aí eu preciso especificar
esse endereço.

Se nós acessamos, por exemplo,
o site do Google,

já podemos ver
como é que esse cara 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
vertodos 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 a 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

do assinar com a chave privada
e ler com a chave pública.

Outro detalhe importante é que nós
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 trekkings,

que são os acessos
que estamos pedindo.

Os trekkings 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.

Ela é 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 to 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 disponibilizei
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.