O documento discute os conceitos fundamentais por trás de APIs RESTful, como URIs, URLs, recursos, verbos HTTP e status HTTP. Também aborda as diferenças entre REST e SOAP, destacando que REST não requer JSON e pode retornar qualquer formato de dados, enquanto promove a utilização de HATEOAS para fornecer links entre recursos.

1. REST NÃO É
SIMPLESMENTE
RETORNAR JSON:
INDO ALÉM COM
APIS REST
Cleber Lopes Campomori
Líder de Conteúdo e Inovação
TreinaWeb

2. QUAL É O PROBLEMA?
▪ Softwares hoje são distribuídos;
▪ Web, Mobile, Desktop, Jobs...
▪ Softwares hoje precisam ser executados em ambientes
heterogêneos;
▪ Tecnologias e linguagens diferentes
▪ As informações precisam estar ”em todo lugar”;
▪ Os softwares hoje precisam conversar entre si!
▪ Integrações!

3. E AGORA?!?!?!?

4. ANTES, ALGUNS CONCEITOS...

5. URI x URL x URN
▪ URIs identificam um recurso!
▪ Geralmente possibilitam a interação entre recursos disponibilizados
em uma rede;
▪ URIs podem ser de dois ”tipos”:
▪ URLs: dizem respeito à localização do recurso;
▪ URNs: dizem respeito ao nome e identificação de um recurso.

6. URI x URL x URN
URI
12º. JUG Vale
(URN)
Av. Eng. Francisco José Longo, nº 777
(URL)
URI
teste.txt
(URN)
file:////home/jugvale/teste.txt
(URL)

7. O PROTOCOLO HTTP
▪ HTTP: HyperText Transfer Protocolo – Protocolo de
Transferência de HiperTexto;
▪ Protocolo de comunicação;
▪ Modelo cliente-servidor;
▪ Definido e ”coordenado” pela W3C;
▪ Está na versão HTTP/2, embora a maioria ainda utilize a versão
HTTP/1.1;
▪ Se baseia em URIs;
▪ A base da Web como conhecemos atualmente.

8. CARACTERÍSTICAS DO PROTOCOLO
HTTP
▪ Protocolo cliente-servidor
▪ O tráfego de informações ocorre em uma via dupla entre o cliente
(quem solicita alguma coisa) e o servidor (quem deve prover essa
coisa).
▪ A solicitação do cliente é chamada de request;
▪ A resposta do servidor é chamada de response.
Cliente Rede Servidor
Request
Response

9. CARACTERÍSTICAS DO PROTOCOLO
HTTP
▪ O protocolo não é ”keep-alive” por padrão
▪ Quando o ciclo Request/Response se encerra a conexão também é
encerrada (mas dá pra manter com keep-alive);
▪ As conexões são independentes
▪ Uma conexão não ”se conecta” ou conhece outras conexões
▪ Por decorrência, o protocolo HTTP é stateless
▪ Se a conexão não é mantida e as conexões são independentes,
como guardar informações?

10. CARACTERÍSTICAS DO PROTOCOLO
HTTP
▪ O protocolo HTTP é semântico
▪ Uma URI pode responder das mais variadas maneiras dependendo
da semântica da requisição;
▪ A natureza dos requests é definida pelo verbo HTTP;
▪ A natureza dos responses é definida pelo status HTTP;
▪ Desenvolvedores que precisam trafegar dados através do protocolo
HTTP DEVEM saber destes conceitos.

11. CARACTERÍSTICAS DO PROTOCOLO
HTTP
▪ Principais verbos HTTP
Verbo HTTP Semântica Exemplos
GET Recuperação de informações no servidor Uma consulta a uma tabela
POST Inserção de informações no servidor A ação de inserção em um cadastro
PUT Alteração de informações no servidor A ação de alteração em um cadastro
DELETE Deleção de recursos no servidor A ação de deleção em um cadastro

12. CARACTERÍSTICAS DO PROTOCOLO
HTTP
▪ Principais status HTTP
Status HTTP Semântica Exemplos
1xx Informação: notificação do cliente de que
a requisição está sendo processada
100 (Continue), 101 (Switching
Protocols)...
2xx Sucesso: a requisição foi processada com
sucesso
200 (OK), 202 (Accepted), 206 (Partial
Content)...
3xx Redirecionamento: uma ação adicional
deve ser realizada para completar a
requisição
302 (Found), 305 (Use Proxy), 307
(Temporary Redirect)...
4xx Erro: a requisição não pôde ser atendida 404 (Not Found), 406 (Not
Acceptable), 410 (Gone)...
5xx Erro no servidor: a requisição era válida,
mas o servidor encontrou um erro ao
processá-la
502 (Bad Gateway), 500 (Internal
Server Error), 599 (Network Connect
Timeout)...

13. BOM, E AGORA?!?!?!?

14. SOAP: O AVÔ DAS INTERFACES WEB
▪ Simple Object Access Protocol – Protocolo de Acesso Simples a
Objetos;
▪ Definido como protocolo por Dave Winer, Don Box, Bob Atkinson,
and Mohsen Al-Ghosein (Microsoft);
▪ Fortemente baseado em XML;
▪ Se utiliza de vários protocolos de transmissão, pois a transmissão
é transparente
▪ Geralmente é baseado em RPC sob HTTP;
▪ É (bem) usado até hoje (e acredito que vá continuar a ser
utilizado por um bom tempo...)

15. SOAP: O AVÔ DAS INTERFACES WEB
▪ Estrutura de uma requisição SOAP
Requisição -
Cliente
Rede
Servidor
Request
Response
Envelope SOAP
SOAP
Header
SOAP Body
Envelope SOAP
SOAP
Header
SOAP Body
SOAP Fault
Chamada RPC

16. SOAP: O AVÔ DAS INTERFACES WEB
▪ Vantagens
▪ O formato de transporte de dados fica transparente no envelope;
▪ Fácil integração com demais tecnologias por se basear em XML;
▪ As chamadas RPC podem tornar os serviços expostos mais ”claros”;
▪ Provê mais ”segurança” pelos mecanismos característicos do XML.
▪ Desvantagens;
▪ Justamente ser baseado em XML: processamento é muito pesado;
▪ Exige uma stack mais complexa;
▪ Verbosidade excessiva

17. EIS QUE SURGE UM HERÓI...

18. REST: O ”CARA” DO MOMENTO
▪ É um modelo arquitetural
▪ Não é tecnologia!
▪ Não é framework!
▪ Não é linguagem!
▪ Criado por Roy Fielding
▪ Um dos criadores do protocolo HTTP
▪ Visa utilizar o protocolo HTTP de maneira mais ”efetiva”
▪ Foco em semântica;
▪ Transações mais leves

19. PILARES PARA UMA API REST
▪ Trata-se de um modelo stateless (HTTP)
▪ Trata-se de um modelo cliente-servidor (HTTP)
▪ Trata-se de uma representação que deve ser ”cacheável”
(HTTP)
▪ É um princípio que é transparente à
tecnologia/linguagem/framework (HTTP)
▪ É baseado em recursos
▪ Pode transmitir dados em qualquer formato!

20. ”PERA” AÍ! PRA SER REST, NÃO TENHO
QUE USAR JSON!??

21. A VELHA ”TRETA”: XML x JSON

22. UMA API REST PODE RETORNAR O QUE
QUISER!
▪ ”Bora” usar o Content Negotiation! ☺

23. REST x RPC (SOAP)
REST RPC/SOAP
Fundação em recursos Fundação em serviços
GET /usuarios /usuarios/getUsuarios
POST /usuarios /usuarios/inserirUsuario
PUT /usuarios/{id}
/usuarios/atualizarUsuario?id={id}
(ou no SOAP body)
DELETE /usuarios/{id}
/usuarios/deletarUsuario?id={id}
(ou no SOAP body)
GET /usuarios/porNome/{nome}
/usuarios/getUsuariosPorNome?nome={nome}
(ou no SOAP body)

24. O ”CALCANHAR DE AQUILES”:
HATEOAS
▪ Hypermedia as the Engine of Application State – Hipermídia
como Mecanismo de Estado da Aplicação
▪ Sétima arte do REST: sem ele, você não está utilizando REST
direito
▪ Os recursos não são simplesmente tráfego de dados!
▪ Eles também devem fornecer que tipo de ações podem ser realizada
com eles
▪ Hypermedia Driven Application (HDA)
▪ Auxilia no processo de escalabilidade e interface única.

25. O ”CALCANHAR DE AQUILES”:
HATEOAS
▪ Um problema grave! JSON não dá suporte ”natural” a
hiperlinks como o XML!
▪ Solução no JSON: representação através de um recurso
adicional…

26. REPRESENTAÇÕES DE RECURSOS
BASEADOS NO HATEOAS
XML
HTTP/1.1 200 OK
Content-Type: application/xml
[...]
<?xml version="1.0"?>
<account rel=”_self" href="https://bank.example.com/account/12345">
<account_number>12345</account_number>
<balance currency="usd">-25.00</balance>
<link rel="deposit” href="https://bank.example.com/account/12345/deposit" />
</account>

27. REPRESENTAÇÕES DE RECURSOS
BASEADOS NO HATEOAS
JSON
HTTP/1.1 200 OK
Content-Type: application/json
[...]
{
"account_number": 12345,
"balance": {
"currency": "usd”
}
"links": [{
"rel": "deposit",
"href": "https://bank.example.com/account/12345/deposit"
}, {
"rel": ”_self",
"href": "https://bank.example.com/account/12345"
}]
}

28. CONCLUSÕES...

29. Cleber Lopes
cleber.campomori@treinaweb.com.br
fb.com/cleber.campomori
linkedin.com/in/clebercampomori
Obrigado! =)