LearnReally
by learnreallyin PortugueseCurated

Available inPortugueseEnglishFrenchGermanHindiRussianSpanish

HTTP e REST para entrevistas de backend

Diga por que um código de status, um cabeçalho ou um atributo de cookie se comporta daquele jeito, e leia uma troca quebrada até achar a falha. Para desenvolvedores de backend que já publicaram APIs REST e nunca precisaram explicá-las em voz alta. Oitenta e oito cartões seguem uma requisição: a mensagem, os métodos, os status, o cache, cookies e CORS, os trade-offs do REST, HTTP/2 e 3, e tokens de login; classes de vulnerabilidade ficam com o baralho de OWASP.

88cards1imports
Try it first
Contents

Card 1 of 88

O slot B é o único campo de cabeçalho que toda requisição HTTP/1.1 é obrigada a levar. Nomeie o campo e diga o que ele faz.

Host. Ele nomeia a autoridade a que a requisição se destina, e é por isso que um mesmo endereço consegue servir muitos sites.

Hints

A linha inicial não traz a autoridade, então algo precisa informá-la.

Source

RFC 9110 §7.2: o cliente TEM QUE enviar Host numa requisição HTTP/1.1, e o servidor que não o recebe responde 400. A hospedagem virtual existe por causa desse campo. HTTP/2 e HTTP/3 o trocam pelo pseudo-cabeçalho :authority, com a mesma informação. Vale para o curso inteiro: em português falamos cabeçalho e requisição, mas o que você digita, e o que o DevTools mostra, é sempre o token em inglês — Host, Content-Type, Accept. Traduzir aqui é errar.