APIs Web RESTFul - QConSp 2014

2,306
-1

Published on

Conheça nesse tutorial como criar APIs web, com ênfase no estilo arquitetural REST. Veja também tópicos relacionados, como HATEOAS, formatos de mensagens, caching, versionamento e workflows de hypermedia.

Alguns dos tópicos abordados:
Características de uma boa API;
Como classificar APIs RESTful com base no modelo Richardson de maturidade;
Como construir uma verdadeira API RESTful;
Como (e quando) utilizar a Hypermedia (HATEOAS) para aumentar a flexibilidade, escalabilidade e interoperabilidade da minhas APIs;
Como se beneficiar da infraestrutura provida pelo HTTP.

O tutorial será composto de um equilíbrio entre ferramental teórico e aplicação prática, e os participantes sairão com conhecimentos concretos para construir e classificar suas próprias APIs Web RESTful.

0 Comments
10 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,306
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

No notes for slide

APIs Web RESTFul - QConSp 2014

  1. 1. APIs Web RESTful QConSp2014
  2. 2. (former) RESTfarian
  3. 3. Agenda Introdução Web REST APIs Web e HTTP Construindo APIs REST Estudo de caso Melhores Práticas
  4. 4. Quem são vocês?
  5. 5. Lembretes
  6. 6. Por que estamos aqui?
  7. 7. APIs Web RESTful
  8. 8. APIs WebRESTful
  9. 9. Por que a Web?
  10. 10. O que ela tem de tão especial?
  11. 11. WWW Global Inúmeras PlataformasEscalável ! Evolução sem quebra de compatibilidade
  12. 12. Propriedades WWW Fácil adoção Deploys incrementais Identificadores e referências transparentes Extensível Simples
  13. 13. APIs Web RESTful
  14. 14. Roy Fielding teve uma epifania…
  15. 15. “Architectural Styles and the Design of Network-Based Software Architectures"
  16. 16. REST REpresentationalStateTransfer RoyFieldingDissertation ESTILODEARQUITETURADESOFTWAREPARASISTEMAS DISTRIBUÍDOSHYPERMEDIASEMELHANTESAWORLD WIDEWEB
  17. 17. Estilo arquitetural
  18. 18. Componente Dados Instruções + Estado provê dados através de uma interface Faz a comunicação Informação transferida
  19. 19. Estilo arquitetural {c1, c2, c3,..} Série de restrições (constraints) de papéis e relacionamentos
  20. 20. Tese do Roy Fielding
  21. 21. REST L(COD)C$SS+U Layered Code- on- demand Client-Server Caching Stateless Uniform Interface
  22. 22. APIsWeb RESTful
  23. 23. API Application Programming Interface “Funções" de comunicação entre provedores e consumidores Públicas e Privadas
  24. 24. API Business Models
  25. 25. API Business Models API é o produto
  26. 26. API Business Models API é a mola
 propulsora do produto
  27. 27. API Business Models API promove o produto
  28. 28. API Business Models API expande o produto
  29. 29. http://www.mediabistro.com/alltwitter/files/2011/07/api_billionaires_club.png
  30. 30. http://dyn.com/blog/research-dynect-api-usage-managed-dns/
  31. 31. Web
  32. 32. +
  33. 33. RESTful APIs
  34. 34. Vamos construí-las?
  35. 35. Modelo OSI
  36. 36. http://1.bp.blogspot.com/-yPHtWF43D8c/TY-PxT-KqNI/AAAAAAAAAAo/1OaBHHrsEKE/s1600/osi-model-7-layers.png
  37. 37. Protocolo de Aplicação define: Tipo de mensagens Sintaxe e semântica das mensagens Regras de comunicação
  38. 38. Web
  39. 39. Captain Obvious… :) A web é composta por Recursos/Objetos Recursos podem ser representados por; página HTML, imagem JPEG, JSON, XML, áudio Cada recurso é endereçável através de uma URL/URI ! www.puglovers.com/pugs/dorinha
  40. 40. HTTP
  41. 41. HTTP HTTP: hypertext transfer protocol Protocolo da camada de aplicação Modelo cliente servidor cliente: requisita um objeto através do protocolo HTTP servidor: envia objetos em respostas as requisições PC running Firefox browser server running Apache Web server iphone running Safari browser HTTP requestHTTP response HTTP request HTTP response
  42. 42. HTTP Usa TCP Cliente inicia uma conexão TCP (cria um socket) Servidor aceita a conexão de um cliente Mensagens HTTP (protocolo de aplicação) trocadas entre o cliente e o servidor HTTP Conexão TCP fechada Stateless Servidor não mantém informações sobre requisições antigas dos clientes
  43. 43. HTTP - Conexões non-persistent HTTP Um objeto é enviado pela conexão TCP Download de múltiplos objetos exige múltiplas conexões TCP persistent HTTP Múltiplos objetos podem ser enviados através de uma única conexão TCP entre cliente e servidor
  44. 44. HTTP - Request GET /index.html HTTP/1.1rn Host: www.ederign.mern User-Agent: Firefox/3.6.10rn Accept: text/html,application/xhtml+xmlrn Accept-Language: en-us,en;q=0.5rn Accept-Encoding: gzip,deflatern Accept-Charset: ISO-8859-1,utf-8;q=0.7rn Keep-Alive: 115rn Connection: keep-alivern rn request line (GET, POST, HEAD) header lines
  45. 45. HTTP - Request
  46. 46. HTTP - Métodos HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT DELETE
  47. 47. HTTP - Response
  48. 48. HTTP Response status codes Primeira linha do response Informational 1xx Successful 2xx Redirection 3xx Client Error 4xx Server Error 5xx
  49. 49. Cookies: user server state
  50. 50. Web caches (proxy server) Meta: satisfazer requisições sem envolver o servidor Usuário utiliza cache no browser Browser envia todas as requisições para o cache Se o objeto já está em cache: retorna o objeto Senão, pede ao servidor destino, armazena e envia ao cliente Servidor não mantém informações sobre requisições antigas dos clientes
  51. 51. Web caches Reduzem o tempo de resposta das requisições ! Reduz o tráfego no link de dados ! Natureza da arquitetura da Internet
  52. 52. Gets Condicionais Objetivo: verificar se o cache tem a versão correta do objeto Cache: específica para o servidor a versão (data ou etag) da versão em cópia em um HTTP request If-modified-since: <date> Servidor: objeto ou resposta se a versão atual é válida HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> HTTP response HTTP/1.0 304 Not Modified object not modified before <date> HTTP request msg If-modified-since: <date> HTTP response HTTP/1.0 200 OK <data> object modified after <date> client server
  53. 53. Local Cache “The Proxies” Translation Proxy Reverse Proxy Web Server Web caches
  54. 54. Pause and REST…
  55. 55. REST é fácil?
  56. 56. REST PODE SER fácil
  57. 57. Omundo,antesdeREST
  58. 58. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  59. 59. TEMPOSDIFÍCEIS... ! MUITOS “PADRÕES” RMI, Corba, DCOM MUITOSFORNECEDORES Sun, Microsoft, OASIS, OMG MUITASLÁGRIMAS Não existia interoperabilidade Reinvenção da roda Vendor “lock-in”
  60. 60. SOAPWEBSERVICES
  61. 61. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  62. 62. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  63. 63. EntãosurgiuoREST!!!
  64. 64. REST REpresentationalStateTransfer RoyFieldingDissertation ESTILODEARQUITETURADESOFTWAREPARASISTEMAS DISTRIBUÍDOSHYPERMEDIASEMELHANTESAWORLD WIDEWEB
  65. 65. PRINCÍPIOSERESTRIÇÕESREST ! CLIENTE-SERVIDOR SERVIDORSTATELESS CACHE INTERFACEUNIFORME IDENTIFICAÇÃO DE RECURSOS MANIPULAÇÃO DESTES RECURSOS ATRAVÉS DE REPRESENTAÇÕES MENSAGENS AUTO-DESCRITIVAS HYPERMEDIACOMO ENGINEDOESTADODAAPLICAÇÃO ARQUITETURAEMCAMADAS CÓDIGOSOBDEMANDA (OPCIONAL)
  66. 66. CACHE HATEOAS HTTP tunning
  67. 67. PUT Recuperar representações de recursos Criar um novo recurso Atualizar (todo o) recurso existente Remover um recurso Atualizar (parte de) um recurso existente DELETE PATCH POST GET
  68. 68. VERBO URI(Substantivo) Ação POST /bookmarks/create Criar GET /bookmarks/show/1 Visualizar POST /bookmarks/update/1 Alterar GET/POST /bookmarks/delete/1 Apagar NÃORESTful VERBO URI(Substantivo) Ação POST /bookmarks/ Criar GET /bookmarks/1 Visualizar PUT /bookmarks/1 Alterar DELETE /bookmarks/1 Apagar RESTful
  69. 69. NOSSOS SONHOS NA INTEGRAÇÃO DESISTEMAS ESCALABILIDADE SEGURANÇA BAIXO ACOPLAMENTO TOLERÂNCIA A FALHAS BALANCEAMENTO DE CARGA
  70. 70. Mas extremamente mal compreendida...
  71. 71. “O que precisa ser feito para que entendam que no estilo arquitetural REST o hypertext é um pré-requisito? Em outras palavras, se a engine do estado da aplicação (e consequentemente sua API) não é guiada por hypertext, então sua aplicação não pode ser RESTful e nem ter uma APIREST. PONTO. Existe por ai algum manual que necessite ser consertado?” “ Roy Thomas Fielding
  72. 72. HYPERMEDIA
  73. 73. Richardson’s Maturity Model Nível 0: O pântano do POX Nível1: Recursos Nível 2: Verbos HTTP Nível 3: Controles Hypermedia REST Sagrado
  74. 74. Nível0:OpântanodoPOX Uma URI, um método HTTP XML-RPC / SOAP / POX HTTP usado como transporte POST /agendamentoService HTTP/1.1 [headers...] ! <appointmentRequest> <slot doctor = "rcmito" start = "1400" end = "1450"/> <patient id = "ederi"/> </appointmentRequest>
  75. 75. Nível1:Recursos Cada recurso tem uma única URI URI tunneling Um único verbo HTTP (POST ou GET) HTTP usado como transporte POST /slots/1234 HTTP/1.1 [headers...] ! <appointmentRequest> <patient id = "ederi" /> </appointmentRequest>
  76. 76. Level2:HTTPVerbs Muitas URIs, utilizando corretamente os verbos HTTP Uso correto dos códigos de resposta Expõe estado e não comportamento CRUD GET /doctors/rcmito/slots?date=20121010?status=open HTTP/1.1 [headers...] HTTP/1.1 200 OK ! <openSlotList> <slot id = “1234” start=”1400” end=”1450” /> <slot id = “1234” start=”1600” end=”1650”/> </openSlotList>
  77. 77. Níveis0,1e2 nãosãoRESTful (enemREST)
  78. 78. Nível3:ControlesHypermedia Hypermedia As The Engine of Application State (HATEOAS) ! Recursos auto descritivos ! Clientes só precisam saber a URI root (home page) de uma API e os media types utilizados ! O resto é HTTP e links
  79. 79. O nome RepresentationalStateTransferfoi escolhido com a intenção de criar uma imagem de como uma aplicação Web bem desenvolvida se comporta: uma rede de páginas web (máquina de estados), onde o usuário navega selecionando links (transições de estados), resultando na próxima página (próximo estado da aplicação). “ Roy Thomas Fielding
  80. 80. ESTADO ESTADOESTADO ESTADOESTADO http://uri Transição Transição Transição Transição
  81. 81. HTTP/1.1 201 Created Location: http://jogano10.com/slots/1234/appointment [various headers] ! <appointment> <slot id = "1234" doctor = "rcmito" start = "1400" end = "1450"/> <patient id = "ederi"/> <link rel = "/linkrels/appointment/cancel" uri = "/slots/1234/appointment"/> <link rel = "/linkrels/appointment/addTest" uri = "/slots/1234/appointment/tests"/> <link rel = "self" uri = "/slots/1234/appointment"/> <link rel = "/linkrels/appointment/updateContactInfo" uri = "/patients/ederi/contactInfo"/> </appointment>
  82. 82. Istoé RESTFUL
  83. 83. RESTfarian
  84. 84. (former) RESTfarian
  85. 85. Vamos construí-las?
  86. 86. Princípios Básicos
  87. 87. Recursos Nomes NUNCA verbos
  88. 88. Será mesmo? /getAccount /updateAccount /verifyAccountBalance
  89. 89. Será mesmo? /getAccount /getAccountActive /getAllAccounts /getGroupAccounts /updateAccount /updateAccountName /updateAccountAddress /updateAccountMembers /updateAccountBalance /verifyAccountBalance /verifyAccountBalanceWithLimit
  90. 90. Será mesmo? /getAccount /getAccountActive /getAllAccounts /getGroupAccounts /updateAccount /updateAccountName /updateAccountAddress /updateAccountMembers /updateAccountBalance /verifyAccountBalance /verifyAccountBalanceWithLimit RPC
  91. 91. Recursos
  92. 92. KISS Recurso Reflete um estado Representações
  93. 93. KISS Recurso Coleção Instância
  94. 94. Coleção /pugs
  95. 95. JAX-RS API
  96. 96. @Path("/cartao/{cardId}") public class Cartao { ! @GET @Produces("text/plain") public Saldo saldo(@PathParam("cardId") String card) { return Response.ok(getSaldo(card)).build(); } ... } HTTPMethod Binding Serialização automática Recursos Injeçãodos parâmetros JAX-RSAPI
  97. 97. @Path("pugs")! public class PugsResource {! ! @GET! @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })! public Response getAll() {! Pugs allPugs = PugsRepository.findAll();! return Response.ok( allPugs ).build();! }! ! }!
  98. 98. Instância /pugs/1
  99. 99. Comportamento
  100. 100. Comportamento GET / PUT / POST / DELETE / HEAD
  101. 101. 1:1 CRUD GET DELETE HEAD
  102. 102. != CRUD PUT e POST
  103. 103. Response Body
  104. 104. Negociação de Conteúdo Accept Header Response: Content-Type header GET puglovers.com/pugs/1 Accept: application/json, text/plain application/vnd[...]+json
  105. 105. Extensão no recurso puglovers.com/pugs/1.json puglovers.com/pugs/1.xml
  106. 106. Versionamento
  107. 107. Versionamento https://api.puglovers.com/v1 Media-Type: application/foo_json;application&v=1 https://v1.api.puglovers.com/
  108. 108. Versionamento - Estratégias REST API! VX Cliente ! 1 Cliente ! 2 Cliente ! n…
  109. 109. Versionamento - Estratégias REST API! V1 Cliente ! 1 … REST API! V2 Cliente ! 1 REST API! Vn Cliente ! n
  110. 110. Versionamento - Estratégias REST API! V1 Cliente ! 1 … REST API! V2 Cliente ! 1 REST API! Vn Cliente ! n
  111. 111. http://www.infoq.com/news/2013/12/api-versioning
  112. 112. HREFs
  113. 113. HREFs Hypermedia distribuída Todo recurso tem uma URL única Pré-requisito para HATEOAS (linking)
  114. 114. HREFs http GET http://localhost:8080/pugs/1 Accept:application/json { "href": "http://api.puglovers.com/pugs/1", "id": 1, "name": "Dorinha", "peso": 10 }
  115. 115. HREFs http GET http://localhost:8080/pugs/1 Accept:application/json { "id": 1, "meta": { "href": "http://api.puglovers.com/pugs/1", "mediaType": "application/json" }, "name": "Dorinha", "peso": 10 }
  116. 116. Paginação
  117. 117. { "pug": [ { "id": 1, "meta": { "href": "http://api.puglovers.com/pugs/1", "mediaType": "application/json" }, "name": "Dorinha", "peso": 10 }, { "id": 2, "meta": { "href": "http://api.puglovers.com/pugs/2", "mediaType": "application/json" }, "name": "Bentao", "peso": 12 }, { "id": 3, "href": "http://api.puglovers.com/pugs/3", "mediaType": "application/json" }, "name": "Eva", "peso": 5 } …. ] } http GET http://localhost:8080/pugs
  118. 118. { "first": "http://api.puglovers.com/pugs?offset=0&limit=2", "items": [ { "id": 1, "meta": { "href": "http://api.puglovers.com/pugs/1", "mediaType": "application/json" }, "name": "Dorinha", "peso": 10 }, { "id": 2, "meta": { "href": "http://api.puglovers.com/pugs/2", "mediaType": "application/json" }, "name": "Bentao", "peso": 12 } ], "last": "http://api.puglovers.com/pugs/100", "limit": "2", "meta": { "href": "http://api.puglovers.com/pugs?offset=0&limit=2", "mediaType": "application/json" }, "next": "http://api.puglovers.com/pugs?offset=2&limit=2", "offset": "0" } http GET http://localhost:8080/pugs?offset=50&limit=25
  119. 119. Representações parciais
  120. 120. Gets Parciais http GET http://localhost:8080/pugs/1?fields=name,peso Accept:application/json { "name": "Dorinha", "peso": 10 }
  121. 121. Erros
  122. 122. Erros Os mais descritivos possível Com o maior número de informações possível
  123. 123. 409 Conflict { “status”:409,
 “code”:1234, “property”:nome, “message:”A pug with name ‘Dorinha' already exists.”. “moreInfo”:”http://api.puglovers.com/docs/api/errors/1234 } http POST http://localhost:8080/pugs
  124. 124. IDs
  125. 125. IDs Não devem ser sequenciais Únicos globalmente
  126. 126. Segurança
  127. 127. Segurança Evite sessões sempre que possível Autorize pelo conteúdo, não pela URL Use um protocolo existente (Oauth 1,2, SSL)
  128. 128. Media Types
  129. 129. Media Type Especificação de Formato Request: Accept Header Response: Content-Type header Content-Type: application/xml Accept: application/json
  130. 130. Caching
  131. 131. HTTP CachingLocal Cache “The Proxies” Translation Proxy Reverse Proxy Web Server
  132. 132. HTTPCaching features allowed (or not) expiration intermediary caches allowed (or not) validation storable(or not)
  133. 133. HTTP Quando “cachear”? Expires header Expires: Sun, 04 Aug 2012 16:00 GMT Cache-control header Cache-Control: no-cache ! Cache-Control: public, max-age=3000 Validation Header Last-Modified: Mon, 29 Jun 2012 02:28:12 GMT! ETag: "3e86-410-3596fbbc"
  134. 134. HTTPHTTP/1.1 200 OK! Content-Type: application/json! Cache-Control: private, max-age=86400! Last-Modified: Thu, 07 Feb 2014 11:56 EST private public no-cache no-store no-transform max-age s-maxage
  135. 135. GET @Path("{id}") @Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML }) public Response getPugBy( @PathParam("id") String id, @Context Request request ) { Pug pug = PugsRepository.findById( id ); if ( pug == null ) { return Response.status( 404 ).build(); } ! CacheControl cc = new CacheControl();! cc.setMaxAge(86400);! cc.setPrivate(true); ResponseBuilder builder = Response.ok(pug); builder.cacheControl(cc); return builder.build(); }
  136. 136. http GET http://localhost:8080/pugs/1
  137. 137. Concorrência
  138. 138. PUT Condicional 412 Precondition Failed caso ETag não for a mais recente do servidor
  139. 139. Mas e se…
  140. 140. http://banco.com.br/contas/1 HTTP/1.1 200 OK Content-Length: 57 Content-Type: application/json Date: Sun, 06 Apr 2014 15:20:50 GMT ! { "id": "1", "saldo": 1264385627, "titular": "Eder Ignatowicz" }
  141. 141. E para transferir entre duas contas? saldo=100 saldo=80 PUT (saldo - valor) PUT (saldo + valor) http://banco.com.br/contas/id
  142. 142. Transações Distribuídas
  143. 143. Você não quer transações em HTTP
  144. 144. E como resolvo? saldo=100 saldo=80 PUT (saldo - valor) PUT (saldo + valor) http://banco.com.br/contas/id
  145. 145. Mapeie em recursos Conta1! saldo=120! Conta2! saldo=80 PUT Conta1(saldo - valor) Conta2(saldo + valor) http://banco.com.br/transferencia/id
  146. 146. Isto resolve tudo?
  147. 147. E como resolvo? Sistema 1 Sistema 2 PUT (comprar passagem) PUT (reservar quarto) http://ciaarea.com.br/311b/7a http://hotel.com/11/7a
  148. 148. Transações Distribuídas
  149. 149. Você não quer transações em HTTP
  150. 150. Você não consegue fazer transações sobre HTTP
  151. 151. Restrições Interoperabilidade Sem mudanças e extensões no HTTP (verbos adicionais, headers especiais)
  152. 152. Restrições Baixo acoplamento Os serviços não devem saber que estão em contexto transacional
  153. 153. Transações Compensatórias
  154. 154. Try Confirm Cancel
  155. 155. Estado Inicial Try Confirm Cancel Estado Reservado Estado Final Timeout/Cancel TRY CONFIRM
  156. 156. Serviço Passagem Try Confirm Cancel Coordenador Transação Try 1 Confirm Serviço deViagem 2 3 Try ConfirmR1 ConfirmR2 4 5 67 Timeout Timeout Serviço Hotel
  157. 157. TCC Try: reserve Confirm: pague Cancel: libere
  158. 158. "Distributed Transactions Are Evil" http://c2.com/cgi/wiki?DistributedTransactionsAreEvil
  159. 159. "I consider "rest transaction" to be an oxymoron.” Roy Fielding https://groups.yahoo.com/neo/groups/rest-discuss/ conversations/topics/12837
  160. 160. (quase) Não existem Transações Distribuídas Eder Ignatowicz
  161. 161. HATEOAS
  162. 162. ESTADO ESTADOESTADO ESTADOESTADO http://uri Transição Transição Transição Transição
  163. 163. ESTADO ESTADO Transição ESTADO Transição
  164. 164. pug/1 father(?) father ? mother pic
  165. 165. Assync
  166. 166. Service PUT http://puglovers.com/report/id Client 202 Accepted
  167. 167. Service PUT http://puglovers.com/report/id Client 202 Accepted Callback
  168. 168. Manutenção
  169. 169. Service GET http:///id Client 301 / 303 Service GET
  170. 170. Documentação
  171. 171. https://helloreverb.com/developers/swagger http://petstore.swagger.wordnik.com/#!/pet Swagger
  172. 172. Alternativas a REST APIs
  173. 173. API assíncronas Push assíncrono ao invés de request/response WebSockets/AMQP/MQTT/STOMP/Web Hooks Internet das Coisas: status/update de device, dados de sensores
  174. 174. SDKs SKDs específicas acabam virando RPC
  175. 175. Protocolos Binários Otimização de Transferência de Mensagens Apache Thrift -> Facebook Google Protocol Buffers -> Google APIs Apache Avro -> Hadoop
  176. 176. Orquestração / Experience APIS Granuralidade de recursos nem sempre é uma vantagem Pode significar muitos requests
  177. 177. "The future of API design: The orchestration layer" Daniel Jacobson - Diretor de Engenharia Netflix Estudo de Caso
  178. 178. APIs: large set of unknown developers (LSUDs)
  179. 179. Desafios
  180. 180. Desafios Diminuir número de “conversas” Mitigar riscos de deploy Suportar várias linguagens Distribuir operações
  181. 181. Solução: Camada de Orquestração API An API Orchestration Layer (OL) is an abstraction layer that takes generically-modeled data elements and/or features and prepares them in a more specific way for a targeted developer or application Daniel Jacobson small set of known developers (SSKDs)
  182. 182. Mais informações? http://techblog.netflix.com/2012/07/embracing-differences- inside-netflix.html http://thenextweb.com/dd/2013/12/17/future-api-design- orchestration-layer/ http://blog.programmableweb.com/2012/05/15/why-rest- keeps-me-up-at-night/ http://techblog.netflix.com/2011/02/redesigning-netflix-api.html http://techblog.netflix.com/2012/07/embracing-differences- inside-netflix.html http://techblog.netflix.com/2013/01/optimizing-netflix-api.html
  183. 183. API REST Melhores Práticas
  184. 184. Piores Práticas em APIs
  185. 185. O que faz uma API horrível? Achar que teu framework MVC vai ter dar uma boa API REST
  186. 186. O que faz uma API horrível? Não usar HTTP corretamente
  187. 187. O que faz uma API horrível? Documentação ruim
  188. 188. O que faz uma API horrível? Suporte inadequado
  189. 189. O que faz uma API horrível? Não dar apoio aos desenvolvedores
  190. 190. O que faz uma API horrível? Media Types Confusos
  191. 191. O que faz uma API horrível? Complexidade na gestão de segurança
  192. 192. Pra onde eu vou?
  193. 193. http://www.programmableweb.com/ http://www.infoq.com/presentations/netflix-reactive-rest http://www.infoq.com/presentations/netflix-api-evolution http://www.infoq.com/presentations/REST-API-HATEOAS
  194. 194. REST é tudo isto?
  195. 195. NOSSOS SONHOS NA INTEGRAÇÃO DESISTEMAS ESCALABILIDADE SEGURANÇA BAIXO ACOPLAMENTO TOLERÂNCIA A FALHAS Foco no end-user
  196. 196. CACHE HATEOAS HTTP tunning
  197. 197. HYPERMEDIA
  198. 198. Obrigado :)
  199. 199. http://arnebrasseur.net/talks/kodio2014/#/37 http://www.slideshare.net/stormpath/rest-jsonapis Referências http://www.inf.usi.ch/faculty/pautasso/talks/2012/soa-cloud-rest-tcc/rest-tcc.html#/comp-wf-tcc-ex http://www.slideshare.net/edgarsilva/economia-das-apis-uma-viso-de-negcios • http://www.slideshare.net/hustwj/rest-in-practice-2010-03-qcon

×