A apresentação de Mario Guedes discute a importância de entender o protocolo HTTP e a arquitetura REST, ressaltando que REST não é um protocolo, mas um padrão arquitetural que utiliza conceitos do HTTP. O vídeo explora aspectos fundamentais como operações, endereçamento, códigos de status e representação de dados nas interações cliente-servidor. O autor também compartilha recursos adicionais e convites para participação em eventos e oportunidades de trabalho.

2. Entendendo o HTTP para
Entender o REST
Mario Guedes | mario@arrayof.io

3. Vídeo da apresentação
• O vídeo da apresentação está em:
https://youtu.be/x0HT3Dg53i4

4. Olá! Aqui é Mario Guedes!
• Artesão de Software desde 1999
• https://arrayof.io - mario@arrayof.io
• https://eugostododelphi.dev
• Participe do primeiro encontro presencial
• https://www.meetup.com/pt-BR/eugostododelphi/

5. Estamos contratando!
• Iniciando os meus trabalhos na TEx Tecnologia
• https://www.textecnologia.com.br
• https://jobs.solides.com/textecnologia/

6. Motivação
• As ferramentas de desenvolvimento, com suas bibliotecas e
frameworks, abstraem vários conceitos importantes e ainda bem que
é assim!
• Isso nos deixa alheios a esses conhecimentos que eventualmente nos
faz falta principalmente quando as coisas não funcionam direito.
• Daí a importância de nos aprofundarmos um pouco mais no tema
HTTP e REST e vermos como as coisas funcionam por “baixo do capô”.

7. Fontes do exemplo
• Os fontes do projeto que será apresentado está em:
https://github.com/ArrayOf/understanding_HTTP

8. Protocolo
• Na computação protocolo é uma convenção, ou seja, um conjunto de
regras bem definidas que possibilitam a conexão, comunicação e a
transferência de dados entre dois sistemas.
• Temos no nosso dia à dia o protocolo TCP/IP. Ela é onipresente e se
referem à dois protocolos:
• IP – que está na camada de rede
• TCP – que está na camada de transporte
• Sobre o protocolo TCP/IP trafegam os protocolos de aplicação que
possibilitam um software conversar com outro. Entre eles o nosso
HTTP.

9. REST
• “Um sistema complexo que funciona é, invariavelmente, considerado
como evoluído a partir de um simples que funcionava” - John Gall.
• REST não é protocolo de comunicação ou de aplicação.
• Mas sim um padrão de arquitetura que reaproveita conceitos do HTTP
e os estende.
• Um solução aderente ao padrão REST, independentemente da adoção
do protocolo HTTP, é dita como RESTful (com um “l” só, como em
beautiful)

10. REQUISIÇÃO
POST /teste HTTP/1.1#13#10
Host: localhost:8080#13#10
Content-Length: 20#13#10
#13#10
{“msg”: “Ola Mundo”}
Verbo
HTTP
Endereçamento
do Recurso
Versão do
Protocolo
Quebra
de Linha
Conteúdo
Linha
vazia
Cabeçalho
Request
Line

11. RESPOSTA
HTTP/1.1 200 OK#13#10
Server: Delphi#13#10
#13#10
Versão do
Protocolo Status Descrição
Quebra
de LinhaCabeçalho
Linha
vazia
Status
Line
Sem
conteúdo

12. REST: Verbo
• Na requisição HTTP é definido o verbo HTTP – que no REST será a
ação que será executada sobre o recurso
• Temos um conjunto limitado e bem definido de ações:
• GET: Recupera um item ou uma lista de itens
• POST: Solicita a criação de um novo item
• PUT: Solicita a modificação de um item já existente
• PATCH: Solicita a modificação parcial de um item já existente
• DELETE: Solicita a exclusão de um determinado item
• Existem outros verbos porém esses são os mais usuais equivalendo às
operações CRUD

13. REST: Recurso
• Na requisição também é definido o endereçamento do recurso que
será manipulado.
• Perceba que o que será feito já foi definido pelo verbo – aqui
definimos onde será feito
• Exemplos:
• GET /usuarios – Lista todos os usuários
• GET /usuarios/1234 – Recupera os dados do usuário de ID 1234
• POST /usuarios – Cria um novo usuário
• PUT /usuarios/1234 – Modifica os dados do usuário 1234
• DELETE /usuarios/1234 – Delete o usuário de ID 1234

14. REST: Parâmetros de execução
• Algumas operações precisam de parâmetros adicionais para serem executadas
corretamente.
• Chaves de acesso, paginação do resultado, filtro de dados são alguns exemplos.
• Os parâmetros podem ser passados da seguinte forma:
• Query string: Sequência de chave e valor na URL, após o sinal de interrogação e
separados por &
GET /usuarios?pagina=1&limite=10
• Cabeçalho: Sequência de chaves e valor no cabeçalho HTTP. Se não for um
cabeçalho padrão o ideal é iniciar por “X-”
X-Chave-Acesso: 1234567890
• Cookies: Uma forma de trafegar dados persistentes entre o cliente e o servidor.
Também vai no cabeçalho HTTP porém requer uma manipulação diferenciada

15. REST: Status HTTP
• Na resposta vêm um código de status que indica o resultado da
solicitação
• Existe uma tabela padrão porém – em termos de REST – ela pode ser
estendida para ter significados mais específicos

16. REST: Status HTTP
Sucesso:
• 200 – A solicitação foi atendida e possui conteúdo de retorno
• 201 – O recurso foi criado
• 202 – A tarefa foi aceita e está em processamento
• 204 – A solicitação foi atendida e não possui conteúdo de retorno
Erro do lado cliente:
• 400 – Erro genérico
• 401 – Não autorizado
• 403 – Acesso negado
• 404 – Recurso não encontrado
Erro do lado servidor:
• 500 – Erro genérico
• 502 – Não foi possível encaminhar a solicitação
• 504 – Tempo excedido

17. REST: Representação
• Os dados que trafegam entre cliente e servidor precisam ser
representados de alguma forma
• Trata-se da serialização e deserialização de dados
• Há vários formatos possíveis porém os mais usuais são XML e JSON
sendo o JSON o formato preferido em uma solução RESTful
• O cliente informa no cabeçalho Accept os formatos preferidos
• O servidor informa no cabeçalho Content-Type o formato da
informação
• application/json – application/xml – text/csv são alguns dos
valores possíveis

18. Resumo
• Vimos nesta palestra o quanto o HTTP é simples o que torna o REST
simples também.
• Trabalhamos com quatro aspectos: Operações, Endereçamento,
Status de Retorno e Representação.
• Há outros aspectos importantes porém abordamos os fundamentais.
• Visite: https://arrayof.io
• Participe: https://www.meetup.com/pt-BR/eugostododelphi/
• Trabalhe: https://jobs.solides.com/textecnologia/

20. Obrigado! Gracias! Thank you!
Mario Guedes | mario@arrayof.io