REST é a bola vez quando falamos sobre API. As maioria dos serviços que encontramos na web fornece interfaces deste tipo para que possamos desenvolver integrações. Será mesmo que estas APIs podem ser consideradas RESTful? O que é preciso para que uma API seja considerada RESTful? Você sabia que este padrão já existe a mais de 15 anos? Nesta palestra vamos nos aprofundar no tema e entender os conceitos e constraints de um sistema RESTful para que possamos explorar suas vantagens na hora de arquitetar nossa próxima API web.

1. O que é esse tal de REST?
Filipe Ximenes (@xima)

2. Sobre
● Filipe Ximenes (Xima)
○ Recife
○ Vinta
○ 4 anos na comunidade Python
○ Django
○ Javascript
○ APIs

3. https://www.getcinnamon.io/

4. Open source
Tapioca
https://github.com/vintasoftware/tapioca-wrapper

5. Open source
Django boilerplate
https://github.com/vintasoftware/boilerplate
Segunda às 14:05

6. Fishbowl
Amanhã às 14:05

7. O que não é REST

8. Alguns mitos
● REST é um protocolo
● Se é API então é REST
● Se é JSON então é REST
● Se é CRUD então é REST
● Se usa os métodos HTTP
(GET/POST/PUT/DELETE) então é REST

9. REST
não é sobre
APIs

10. O melhor exemplo de sistema RESTfull

11. A World Wide Web
(ou Internet para os mais intimos)

12. História
● 1945 - Memex, "As We May Think", Vannevar
Bush

13. História
● 1989 - Primeira
conexão HTTP
○ Tim Berners-Lee
○ CERN
(Organisation
européenne pour la
recherche
nucléaire) "PROPERTY OF CERN"

14. História
● 1990 - Formalização do HTTP
○ Internet Engineering Task Force (IETF)
○ World Wide Web Consortium (W3C)
● 1997 - HTTP/1.1
○ Participação de Roy Fielding
● 2000 - "Architectural Styles and the Design of
Network-based Software Architectures"
○ Dissertação de doutorado de Roy Fielding
○ REST

15. REST & RESTfullness

16. O que é REST
● Acrônimo para:
REpresentational State Transfer
● pt-br:
Transferência de Estado Representacional
● Estilo Arquitetural
○ Não é um protocolo

17. Alguns conceitos

18. ● Tangíves ou intangíveis
● Recurso != Tabela do banco de dados
○ 1 ou + tabelas
○ Processamento
● Substantivos
Recursos (resources)

19. Recursos (resources)
● Peças de uma bicicleta
● Bicicleta montada
● Trajeto percorrido
● Registro da manutenção da bicicleta
● Acessórios

20. ● Completa ou parcial
● Quantidade por recurso: [0, +infinito)
Representações

21. Representações
● Rodas
● Quadro
● Pedal
● Guidão
● Freios
● Tamanho
● Marca
● Ano
● Modelo

22. Representações
<bicicleta>
<quadro>
<tamanho>52</tamanho>
<cor>preto</cor>
</quadro>
<guidao>
<tamanho>60</tamanho>
</guidao>
</bicicleta>
{
"quadro": {
"tamanho": 52,
"cor": "preto"
}
"guidao": {
"tamanho": 60
}
}

23. HATEOAS
● Hypermedia As The Engine Of Application
State
● Hipermídia Como Motor do Estado da
Aplicação
○ Hipermídia (Links)
○ Transição de estado

24. Transferência de Estado
Representacional (REST)
(ou: como funciona o seu navegador web)

25. Transferência de Estado Representacional
● Queremos acessar o meu perfil no Twitter
[RECURSO]
● Estado inicial: www.twitter.com/
● Clicamos em "ver perfil" [LINK]
● Um servidor web retorna uma página HTML
[REPRESENTAÇÃO]
● Estado final: https://twitter.com/xima

26. Preceitos [constraints] de uma
arquitetura REST
(ou: o que caracteriza um sistema RESTfull)

27. 1. Cliente - Servidor

28. 2. Stateless
● Ausência de estado: o servidor não deve
guardar o estado do cliente.
● A requisição deve conter tudo que é
necessário para o servidor processar a
resposta.

29. 3. Cache
● O cliente deve ser informado sobre as
propriedades de cache de um recurso para
que possa decidir quando deve ou não utilizar
cache.

30. 4. Interface Uniforme
● 4 sub-preceitos
○ Identificação de recursos (URI).
○ Manipulação de recursos a partir de suas
representações.
○ Mensagens auto descritivas.
○ HATEOAS

31. 5. Sistema em camadas
● O cliente não precisa saber sobre as camadas
entre ele o servidor.
● Camadas da internet (HTTP/TCP/IP)
● Caching
○ Browser
○ Servidor
○ Banco de dados

32. 6. Código sob demanda
● O cliente deve ser capaz de atualizar partes
de seu código dinamicamente.
● Não é obrigatório.

33. REST e APIs

34. APIs HTTP e os preceitos do REST
● Cliente - Servidor
● Stateless
● Cache
● Interface Uniforme
○ Identificação de recursos, manipulação de
recursos a partir de suas representações,
mensagens auto descritivas, HATEOAS.
● Sistema em camadas
● Código sob demanda

35. APIs e HATEOAS
"REST APIs must be hypertext-driven"
Roy T. Fielding
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

36. APIs e HATEOAS
http://www.test.com/api
{
"users": "http://www.test.com/api/users",
"companies": "http://www.test.com/api/companies"
}
http://www.test.com/api/users
[
{"name": "Filipe",
"profile": "http://www.test.com/api/users/1"},
{"name": "Flávio",
"profile": "http://www.test.com/api/users/2"}
]
http://www.test.com/api/users/1
{
"name": "Filipe",
"twitter": "@xima",
"company": "Vinta"
}

37. Evolutibilidade
https://twitter.com/fielding/status/376835835670167552

38. Evolutibilidade é a capacidade de
adicionar, remover ou modificar
funcionalidades sem modificar interfaces
https://twitter.com/fielding/status/684109534659411968

39. Não temos controle sobre o mundo!
As regras de negócio mudam o tempo
todo e o sistema evolui
https://twitter.com/fielding/status/647491186937036800

40. REST foi pensado para que os
desenvolvedores estejam preparados
para mudanças.
https://twitter.com/fielding/status/684110775313551360

41. Como aplicar?

42. Precisamos de protocolos!
(mas não precisamos
reescrever os já existentes)
https://twitter.com/fielding/status/684111566304743424

43. Os outros dois preceitos
● Manipulação de recursos
○ As representações entregues ao cliente devem
ser suficientes para que ele seja capaz de realizar
modificações nos recursos.
● Mensagens auto descritivas
○ Respostas devem conter todo o conteúdo
necessário para o cliente tomar decisões de como
proceder.

44. Como aplicar
● Pense bem nas representações dos
recursos do sistema.
○ Desenvolva seus Media-Types
● Documente TUDO
○ O que o cliente deve esperar da requisição?
○ Como deve lidar com erros?
○ Como deve lidar com mudanças?
■ Como lidar com um dado não esperado?

45. Como aplicar
● Utilize os padrões já existentes
○ Métodos do HTTP
■ GET/POST/PUT/PATCH/DELETE
○ Status de resposta do HTTP:
■ 200 OK
■ 201 CREATED
■ 404 NOT FOUND
● Defina mensagens de erro claras

47. REST na vida real

48. Ninguém vai ler a sua documentação

49. Clientes não vão estar preparados para
mudanças na API

50. Você será xingado e odiado por todos os
desenvolvedores

51. Desenvolver um cliente HATEOAS é bem mais
complicado do que parece

52. Sua API não precisa ser
100% RESTfull

53. Twitter: @xima
Github: filipeximenes
Email: ximenes@vinta.com.br
Perguntas?