Desbravando o REST com Python

Talk sobre REST usando exemplos em Python. Foi legal esse dia no Python Campinas :D

1. DESBRAVANDO O REST COM PYTHON @fidelissauro
2. $ whoami Matheus Fidelis Desenvolvedor Backend / DevOps @superlogica Twitter: @fidelissauro E-mail: msfidelis01@gmail.com Github: https://github.com/msfidelis Blog: http://nanoshots.com.br
3. O QUE SÃO API`s? 1
4. “ Application Programming Language
5. API ⊡ Conjunto de recursos e funções. ⊡ Desenvolvimento desacoplado. ⊡ Garantir um acesso uniforme a sua aplicação ⊡ Independente de linguagem, paradigma ou plaforma.
6. “ “Conjunto de “coisinhas” da sua aplicação que você disponibiliza para outras pessoas acessarem da forma que elas quiserem por onde quiserem sem ninguém precisar entender como elas funcionam” - FIDELIS, Matheus
7. API
9. “ Prover uma maneira simples e uniforme para Aplicações Web, Apps Android, IOS, Televisões, Geladeiras, Carros, Cafeteiras, Arduinos, Seres Alienígenas e até mesmo outras API’s a acessarem e modificarem seus dados falando a mesma língua.
10. “
11. RESOURCES 2
12. “ RESOURCES são elementos manipulados a partir de um identificador global. Todos os dados tem ID’s
13. “ Recurso: Cobrança id: api.xuxu.com/cobranca
14. “ A nomeação de um recurso sempre é formada por um substantivo, nunca um verbo. http://api.xuxu.com/cobrar http://api.xuxu.com/cobranca
15. “ URI
16. “ URL
17. VERBOS HTTP 2
18. “ São métodos que podemos utilizar para criar uma API RESTful. Atualmente são 9, e possuem finalidades de aplicar operações a serem efetuadas sob um determinado recurso
19. PRINCIPAIS VERBOS Method Ação GET OBTEM DADOS DE UM REGISTRO POST CRIA UM NOVO REGISTRO PUT SUBSTITUI DADOS DE UM REGISTRO DELETE DELETA UM REGISTRO VERBOS HTTP
20. OUTROS VERBOS Method Ação HEAD RETORNA O CABEÇALHO DA REQUEST OPTIONS RETORNA QUAIS MÉTODOS ESTÃO DISPONÍVEIS PATCH MODIFICAÇÕES PARCIAIS NO REGISTRO TRACE RETORNA A REQUISIÇÃO FEITA PARA COMPARAR MODIFICAÇÕES CONNECT CRIA UMA CONEXÃO TCP COM O SERVIDOR VERBOS HTTP
21. RESPONSE CODES 2
22. RESPONSE CODES CODES STATUS 100* INFORMATION RESPONSES 200* SUCCESSFUL RESPONSES 300* REDIRECTION MESSAGES 400* CLIENT ERROR RESPONSES 500* SERVER ERROR RESPONSES https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
23. O QUE É REST?? 1
24. REST ⊡ REST (Representational State Transfer) ⊡ Formalização de um conjunto de boas práticas do uso do HTTP ⊡ Tirar o melhor proveito possível dos recursos que o HTTP disponibiliza ⊡ Constraints
25. “ CONSTRAINTS??
26. “ “Modelar a forma na qual o HTTP e as URI's deveriam ser modelados para aproveitar todos os seus recursos”
27. “ Cliente / Servidor
28. CLIENTE/SERVIDOR
29. “ Deve-se separar completamente as responsabilidades do Cliente e do(s) Servidor(es) da aplicação.
30. “ Deve-se permitir a evolução e escalabilidade dessas responsabilidades de forma completamente separada
31. “ ⊡ Crescimento do Frontend ⊡ SPA’s ⊡ Aplicações Mobile ⊡ API’s que consomem outras API’s ⊡ Layers da Aplicação
32. “
33. STATELESS
34. “ Cada request para o servidor não devem ter ligações com a futura nem com a anterior.
35. “ Cada request deve conter todas as informações necessárias para que ela seja tratada com sucesso pelo servidor.
36. CACHE
37. “ Uma aplicação REST deve permitir que suas respostas sejam passíveis de cache
38. INTERFACE UNIFORME
39. “ ⊡ Padrões nos Resources ⊡ Mensagens Autodescritivas ⊡ Response Codes
40. GET: /pegarUsuario Status: 200 GET: /usuario Status: 200 POST: /novoUsuario Status: 200 POST: /usuario Status: 201 PUT: /atualizarUsuario Status: 200 PUT: /usuario Status: 200 DELETE: /deletarUsuario Status: 200 DELETE:/usuario Status: 204
41. APPLICATION LAYERS
42. “ Uma aplicação REST deve ter a capacidade de adicionar elementos intermediários de forma transparente Ex: Load Balances, Cache Servers, Gateways, Analytics, WAF e etc.
43. “ Garantir a Escalabilidade entre Sistemas Distribuidos.
45. HATEOAS
46. “ Informar o cliente pra onde ele pode ir depois de uma ação na sua API
47. REST VS SOAP 2
48. “ “O REST é um modelo de arquitetura. O SOAP é um protocolo de rede ao pé da letra”
49. REST VS SOAP REST SOAP MODELO ARQUITETURAL PROTOCOLO REQUESTS VIA HTTP SIMPLES CHAMADAS SOAP EMPACOTADAS QUE UTILIZAM O HTTP PARA EXECUTAR CHAMADAS RPC (REMOTE PROCEDURE CALL) JSON, XML, YAML, HTML... APENAS XML
50. REQUESTS E RESPONSES HTTP 2
51. “ Media Types
52. “ Media Types Media Type é uma string que define qual o formato do dado e como ele deve ser lido. http://www.iana.org/assignments/media-types/media-types.xhtml
53. “ http://www.iana.org/assignments/media-types/media-types.xhtml Media Types Application/json Application/xml Multipart/form-data Text/html
54. “ Content-Type String no Header que identifica o conteúdo da requisição
55. “ Accept A String no Header que identifica qual o formato do retorno que deseja receber do servidor.
56. REST VS RESTFUL 1
57. “ REST é uma convenção de Boas Práticas RESTful é uma aplicação com o REST implementado.
58. “ Se minha API segue os padrões REST, logo ela é uma API RESTful
59. “ Se minha API não segue os padrões REST, logo ela é uma API HTTP
62. REST NÃO É REGRA
63. PYTHON
64. DJANGO FRAMEWORK + DJANGO REST
65. https://www.djangoproject.com/ http://www.django-rest-framework.org/
66. DJANGO REST FRAMEWORK • Extensão do Django Framework • Framework MVC em Python • Configuração um pouco complexa • Várias camadas • Aplicação Modular • Referência em aproveitamento dos recursos HTTP • Suporte para Migrations • Suporte para Serialização • Suporte para Content Negotiation Inteligente • Ideal pra API’s com maior porte e maior numero de devs na equipe
67. BABYSTEPS COM DJANGO Serializer View URL Model Registrar Modulo
68. FLASK
69. http://flask.pocoo.org/
70. FLASK • Micro Framework em Python • Quickstart Rápido • Bem leve e escalável • Muito verboso • Requer muita implementação manual • Ideal pra coisas simples e abstração de recursos da infraestrutura.
71. FLASK
72. https://github.com/msfidelis/restful-talk EXEMPLOS
73. Perguntas?? @fidelissauro msfidelis01@gmail.com https://github.com/msfidelis
74. DOJO