Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

O que é esse tal de rest? [PyBR2016]

916 views

Published on

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.

Published in: Software
  • Login to see the comments

O que é esse tal de rest? [PyBR2016]

  1. 1. O que é esse tal de REST? Filipe Ximenes (@xima)
  2. 2. Sobre ● Filipe Ximenes (Xima) ○ Recife ○ Vinta ○ 4 anos na comunidade Python ○ Django ○ Javascript ○ APIs
  3. 3. https://www.getcinnamon.io/
  4. 4. Open source Tapioca https://github.com/vintasoftware/tapioca-wrapper
  5. 5. Open source Django boilerplate https://github.com/vintasoftware/boilerplate Segunda às 14:05
  6. 6. Fishbowl Amanhã às 14:05
  7. 7. O que não é REST
  8. 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. 9. REST não é sobre APIs
  10. 10. O melhor exemplo de sistema RESTfull
  11. 11. A World Wide Web (ou Internet para os mais intimos)
  12. 12. História ● 1945 - Memex, "As We May Think", Vannevar Bush
  13. 13. História ● 1989 - Primeira conexão HTTP ○ Tim Berners-Lee ○ CERN (Organisation européenne pour la recherche nucléaire) "PROPERTY OF CERN"
  14. 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. 15. REST & RESTfullness
  16. 16. O que é REST ● Acrônimo para: REpresentational State Transfer ● pt-br: Transferência de Estado Representacional ● Estilo Arquitetural ○ Não é um protocolo
  17. 17. Alguns conceitos
  18. 18. ● Tangíves ou intangíveis ● Recurso != Tabela do banco de dados ○ 1 ou + tabelas ○ Processamento ● Substantivos Recursos (resources)
  19. 19. Recursos (resources) ● Peças de uma bicicleta ● Bicicleta montada ● Trajeto percorrido ● Registro da manutenção da bicicleta ● Acessórios
  20. 20. ● Completa ou parcial ● Quantidade por recurso: [0, +infinito) Representações
  21. 21. Representações ● Rodas ● Quadro ● Pedal ● Guidão ● Freios ● Tamanho ● Marca ● Ano ● Modelo
  22. 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. 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. 24. Transferência de Estado Representacional (REST) (ou: como funciona o seu navegador web)
  25. 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. 26. Preceitos [constraints] de uma arquitetura REST (ou: o que caracteriza um sistema RESTfull)
  27. 27. 1. Cliente - Servidor
  28. 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. 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. 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. 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. 32. 6. Código sob demanda ● O cliente deve ser capaz de atualizar partes de seu código dinamicamente. ● Não é obrigatório.
  33. 33. REST e APIs
  34. 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. 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. 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. 37. Evolutibilidade https://twitter.com/fielding/status/376835835670167552
  38. 38. Evolutibilidade é a capacidade de adicionar, remover ou modificar funcionalidades sem modificar interfaces https://twitter.com/fielding/status/684109534659411968
  39. 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. 40. REST foi pensado para que os desenvolvedores estejam preparados para mudanças. https://twitter.com/fielding/status/684110775313551360
  41. 41. Como aplicar?
  42. 42. Precisamos de protocolos! (mas não precisamos reescrever os já existentes) https://twitter.com/fielding/status/684111566304743424
  43. 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. 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. 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
  46. 46. REST na vida real
  47. 47. Ninguém vai ler a sua documentação
  48. 48. Clientes não vão estar preparados para mudanças na API
  49. 49. Você será xingado e odiado por todos os desenvolvedores
  50. 50. Desenvolver um cliente HATEOAS é bem mais complicado do que parece
  51. 51. Sua API não precisa ser 100% RESTfull
  52. 52. Twitter: @xima Github: filipeximenes Email: ximenes@vinta.com.br Perguntas?

×