--- Tipos de Métodos

GET: Buscar recursos

POST : Criar um novo recurso

PUT: Atualiar um recurso existente

DELETE: Remover um recurso

--- Tipos de Respostas:

1xx - Informações Gerais

2xx - Sucesso
3xx - Redirecionamento
4xx - Erro no Cliente
5xx - Erro no Servidor

--- 201 - Created

Retornar Location ao inserir novo dado.

O HTTP é um protocolo sem estado, ou seja, cada requisição é única e não contem por
exemplo uma sessão para manter o “usuário” ou os privilégios, por isso usamos
também o HEADER para enviar informações de autenticação.

Em computação, um protocolo sem estado (do inglês stateless) é um protocolo de

comunicação que considera cada requisição como uma transação independente que não
está relacionada a qualquer requisição anterior, de forma que a comunicação
consista de pares de requisição e resposta independentes.

Um protocolo é um conjunto de regras.

O HTTP é um protocolo que define as regras de comunicação entre cliente e servidor
na internet.
O HTTP é o protocolo mais importante da internet.

Se você compreende este texto, é porque você sabe português! Para que alguém
consiga se comunicar com você, esse alguém deverá usar o português (supondo que
você desconheça outro idioma, é claro). Isso significa que, sua regra (protocolo)
de comunicação com o mundo é a língua portuguesa, que define a forma com que as
informações devem chegar até você )através dp vocabulário, regras de gramática e
etc). Uma outra pessoa que conheça português irá usar do mesmo formato, já que
vocês possuem um idioma em comum.

Na internet, como já vimos, o idioma mais comum é o HTTP. Ele é responsável por
definir a forma de como os dados são trafegados na rede através de várias regras.
Portanto, todo mundo que conhece o idioma HTTP poderá receber e enviar dados e
participar dessa conversa!

Há arquiteturas muito mais complexas, mas a grande maioria usa o protocolo HTTP no
topo. O protocolo HTTP garante a conectividade. Isso quer dizer o protocolo HTTP
funciona em todos os lugares, sem ter problemas com firewall e outras regras de
segurança; Nós podemos nos conectar sem maiores problemas com qualquer servidor do
mundo!

HTTPS
Quando usamos o HTTP, todos os dados enviados entre cliente e servidor são
transmitidos em texto puro, inclusive dados sensíveis como login e senha! O que
pode ser perigoso, já que assim deixamos os dados abertos para intermediários.

Para estes e outros cenários, existe o HTTPS, que basicamente é o HTTP comum, porém
com uma camada adicional de segurança/criptografia que antes era SSL, mas
posteriormente passou a ser também TLS. É muito comum que estas duas siglas sejam
encontradas juntas com SSL/TLS por ser tratarem da mesma questão de segurança.
Sendo assim temos dois termos:

HTTP: HyperText Transfer Protocol

SSL/TLS: Secure Sockets Layer/ Transport Layer Security

O HTTPS para garantir segurança usa criptografia em chaves públicas e privadas e

para gerar essas chaves púlicas e privadas é preciso garantir a identididade de
quem possui essas chaves e isso é feito a partir de um certificado digital, ou
seja, um certificado digital é utilizado para identificar determinada entidade e
ainda é utilizada para geração de chaves de criptografia.

Apesar disso, ainda é necessário que uma autoridade certificadora, que nada mais é
que um orgão ou entidade confiável, garanta não apenas a identidade mas também a
validade do certificado. No caso da Alura a autoridade certificadora é a COMODO RSA
Domain Validation, mas existe outras.

Dito isso, como tudo funciona? Os navegadores em posse da chave pública

criptografam as informações e as enviam para o servidor que as descriptografam com
a chave privada. É importante notar que apenas a chave privada descriptografa as
informações criptogradas com a pública e também que deve-se manter a chave segura.

Só com HTTPS a web é segura.

HTTPS significa usar um certificado digital no servidor.
O certificado prova a identidade e tem validade.
O certificado possui uma chave púclia.
A chave é utilizada pelo navegador para criptografar os dados.

Essa garantia é feita através de uma assinatura digital. A autoridade certificadora

(CA) assina digitalmente o certificado! Como na vida real, existem também no mundo
digital: assinaturas!

Uma autoridadde certificadora (CA - Certificate Authority) é um orgão que garante

ao navegador e ao usuário que a identidade de um servidor (por exemplo o servidor
da Alura) é realmente válida. Portanto, podemos trocar informações com este sem
riscos!

Certificado digital

Quando precisamos informar nossos dados a algum servidor, queremos ter certeza que
este servidor realmente representa a entidade em questão. Queremos confiar em quem
estamos fornecendo nossos dados!

Um certificado digital prova um identidade para um site, onde temos informações

sobre o seu domínio e a data de expiração desse certificado.

Além disso, o certificado ainda guarda a chave pública que é utilizada para
criptografar (cifrar) os dados que são trafegados entre cliente e servidor.

Por padrão, os dados são trafegados como texto pura na web.

Apenas com HTTPS a Web é segura
O protocolo HTTPS nada mais é do que o protocolo HTTP mais uma camada adicional de
segurança, TLS/SSL.
Certificados possuem identidade e validade
As chaves públicas estão no certificado, a chave privada fica apenas no servidor.
O navegador utiliza a chave pública para criptografar os dados.

Portas

A porta reservada para o protocolo HTTP é a 80. Novamente um número, e como o

navegador já sabe essa porta padrão, podemos omití-la, mas nada nos impede
adicioná-la no endereço.
O protocolo HTTPS possui uma porta padrão, a porta 443, que também podemos omitir
ao acessar um endereço HTTPS.
Como as portas padrões são conhecidas pelo navegador, elas podem ser omitidas ao
escrevermos uma URL.

Vários protocolos definem a sua porta padrão como por exemplo o FTP que usa 25 ou
SSH que usa 22.

URL

Muitas vezes, desenvoldores usam a sigla URL (Uniform Resource Identifier) quando
falam de endereço na web, Alguns preferem URL, alguns misturas as duas siglas. Há
uma certa confusão no mercado a respeito e mesmo desenvolvedores experientes não
sabem explicar a diferença. Então, qual é a diferença?

Restosta 1 (fácil): Uma URL é uma URI. No contexto do desenvolvimento web, ambas as
siglas são válidas para falar de endereços na web. As siglas são praticamente
sinônimos e são utilizadas dessa forma.

Resposta 2 (mais elaborada): Uma URL é uma URI, mas nem todas as URI's são URLs!
Existem URI's que identificam um recurso sem definir oendereço, nem o protocolo. Em
outras palavras, uma URL representa uma informação de um recurso (URI) através do
endereço, mas nem todas as identificações são ULR's.As siglas são praticamente
sinônimos e são utilizadas dessa forma.

Stateless

O HTTP é um protocolo que não mantém o estado de requisições. Isso significa que só
com HTTP não há como se lembrar das requisições anteriores enviadas para o
servidor. Por isso precisamos incluir em cada requisição todas as informações
sempre.

Sessão

Uma sessão HTTP nada mais é que um tempo que o cliente permanece ativo no sistema!
Isso é parecido com uma sessão no cinema. Uma sessão, nesse contexto, é o tempo que
o cliente usa a sala no cinema para assistir a um filme. Quando você sai da sala,
termina a sessão. Ou seja, quando você se desloga, a Alura termina a sua sessão.

Cookie

Quando falamos de Cookies na verdade queremos dizer Cookies HTTP ou Cookies web. Um
cookie é um pequeno arquivo de texto, normalmente criado pela aplicação web, para
guardar algumas informações sobre usuário no navegador. Quais são essas informações
depende um pouco da aplicação. Pode ser que fique gravado alguma preferência do
usuário. Ou algumas informações sobre as copmras na loja virtual ou, como vimos no
vídeo, a identificação do usuário. Isso depende de utilidade para aplicação web.

Um cookie pode ser manipulado e até apagado pelo navegador e, quando for salvo no
navegador, fica associado com um domínio. Ou seja, podemos ter um cookie para
www.alura.com.br, e outro para www.caelum.com.br. Aliás, um site ou web app pode
ter vários cookies!

Requisilçao

É importante lembrarmos que a comunicação sempre começa com o cliente: é ele quem
pede as informações. O servidor responde apenas o que foi requisitado e nunca
inicia a comunicação.

Quando devo usar o 301 e o Canonical?

<html>
<head>
<link href="http://www.guj.com.br/java/204576-arquitetura-de-jogos"
rel="canonical" />
</head>
</html

Na essência, os dois fazem a mesma coisa. Indicam que um endereço antigo não deve
mais ser utilizado na indexação. A grande diferença entre eles está na
implementação. O Canonical tende a ser mais fácil de ser adicionado, já que basta a
adição de uma linha de código ao cabeçalho da página e por isso, também, mais
rápida de ser feita.
Por outro lado, a confguração dos redirecionamentos, dependendo de como feita,
tende a fcar centralizada em apenas um lugar no servidor, dessa forma, mais
organizada.
Em suma, são estratégias diferentes para resolver o mesmo problema. Escolha a que
você acreditar ser a melhor na sua situação.