Your SlideShare is downloading. ×
APIs Web RESTFul - QConSp 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

APIs Web RESTFul - QConSp 2014

2,002
views

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 …

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,002
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
10
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. APIs Web RESTful QConSp2014
  • 2. (former) RESTfarian
  • 3. Agenda Introdução Web REST APIs Web e HTTP Construindo APIs REST Estudo de caso Melhores Práticas
  • 4. Quem são vocês?
  • 5. Lembretes
  • 6. Por que estamos aqui?
  • 7. APIs Web RESTful
  • 8. APIs WebRESTful
  • 9. Por que a Web?
  • 10. O que ela tem de tão especial?
  • 11. WWW Global Inúmeras PlataformasEscalável ! Evolução sem quebra de compatibilidade
  • 12. Propriedades WWW Fácil adoção Deploys incrementais Identificadores e referências transparentes Extensível Simples
  • 13. APIs Web RESTful
  • 14. Roy Fielding teve uma epifania…
  • 15. “Architectural Styles and the Design of Network-Based Software Architectures"
  • 16. REST REpresentationalStateTransfer RoyFieldingDissertation ESTILODEARQUITETURADESOFTWAREPARASISTEMAS DISTRIBUÍDOSHYPERMEDIASEMELHANTESAWORLD WIDEWEB
  • 17. Estilo arquitetural
  • 18. Componente Dados Instruções + Estado provê dados através de uma interface Faz a comunicação Informação transferida
  • 19. Estilo arquitetural {c1, c2, c3,..} Série de restrições (constraints) de papéis e relacionamentos
  • 20. Tese do Roy Fielding
  • 21. REST L(COD)C$SS+U Layered Code- on- demand Client-Server Caching Stateless Uniform Interface
  • 22. APIsWeb RESTful
  • 23. API Application Programming Interface “Funções" de comunicação entre provedores e consumidores Públicas e Privadas
  • 24. API Business Models
  • 25. API Business Models API é o produto
  • 26. API Business Models API é a mola
 propulsora do produto
  • 27. API Business Models API promove o produto
  • 28. API Business Models API expande o produto
  • 29. http://www.mediabistro.com/alltwitter/files/2011/07/api_billionaires_club.png
  • 30. http://dyn.com/blog/research-dynect-api-usage-managed-dns/
  • 31. Web
  • 32. +
  • 33. RESTful APIs
  • 34. Vamos construí-las?
  • 35. Modelo OSI
  • 36. http://1.bp.blogspot.com/-yPHtWF43D8c/TY-PxT-KqNI/AAAAAAAAAAo/1OaBHHrsEKE/s1600/osi-model-7-layers.png
  • 37. Protocolo de Aplicação define: Tipo de mensagens Sintaxe e semântica das mensagens Regras de comunicação
  • 38. Web
  • 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. HTTP
  • 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. 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. 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. 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. HTTP - Request
  • 46. HTTP - Métodos HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT DELETE
  • 47. HTTP - Response
  • 48. HTTP Response status codes Primeira linha do response Informational 1xx Successful 2xx Redirection 3xx Client Error 4xx Server Error 5xx
  • 49. Cookies: user server state
  • 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. Web caches Reduzem o tempo de resposta das requisições ! Reduz o tráfego no link de dados ! Natureza da arquitetura da Internet
  • 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. Local Cache “The Proxies” Translation Proxy Reverse Proxy Web Server Web caches
  • 54. Pause and REST…
  • 55. REST é fácil?
  • 56. REST PODE SER fácil
  • 57. Omundo,antesdeREST
  • 58. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  • 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. SOAPWEBSERVICES
  • 61. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  • 62. http://geekswithblogs.net/images/geekswithblogs_net/ugandadotnet/eai-spaghetti.jpg
  • 63. EntãosurgiuoREST!!!
  • 64. REST REpresentationalStateTransfer RoyFieldingDissertation ESTILODEARQUITETURADESOFTWAREPARASISTEMAS DISTRIBUÍDOSHYPERMEDIASEMELHANTESAWORLD WIDEWEB
  • 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. CACHE HATEOAS HTTP tunning
  • 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. 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. NOSSOS SONHOS NA INTEGRAÇÃO DESISTEMAS ESCALABILIDADE SEGURANÇA BAIXO ACOPLAMENTO TOLERÂNCIA A FALHAS BALANCEAMENTO DE CARGA
  • 70. Mas extremamente mal compreendida...
  • 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. HYPERMEDIA
  • 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. 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. 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. 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. Níveis0,1e2 nãosãoRESTful (enemREST)
  • 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. 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. ESTADO ESTADOESTADO ESTADOESTADO http://uri Transição Transição Transição Transição
  • 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. Istoé RESTFUL
  • 83. RESTfarian
  • 84. (former) RESTfarian
  • 85. Vamos construí-las?
  • 86. Princípios Básicos
  • 87. Recursos Nomes NUNCA verbos
  • 88. Será mesmo? /getAccount /updateAccount /verifyAccountBalance
  • 89. Será mesmo? /getAccount /getAccountActive /getAllAccounts /getGroupAccounts /updateAccount /updateAccountName /updateAccountAddress /updateAccountMembers /updateAccountBalance /verifyAccountBalance /verifyAccountBalanceWithLimit
  • 90. Será mesmo? /getAccount /getAccountActive /getAllAccounts /getGroupAccounts /updateAccount /updateAccountName /updateAccountAddress /updateAccountMembers /updateAccountBalance /verifyAccountBalance /verifyAccountBalanceWithLimit RPC
  • 91. Recursos
  • 92. KISS Recurso Reflete um estado Representações
  • 93. KISS Recurso Coleção Instância
  • 94. Coleção /pugs
  • 95. JAX-RS API
  • 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. @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. Instância /pugs/1
  • 99. Comportamento
  • 100. Comportamento GET / PUT / POST / DELETE / HEAD
  • 101. 1:1 CRUD GET DELETE HEAD
  • 102. != CRUD PUT e POST
  • 103. Response Body
  • 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. Extensão no recurso puglovers.com/pugs/1.json puglovers.com/pugs/1.xml
  • 106. Versionamento
  • 107. Versionamento https://api.puglovers.com/v1 Media-Type: application/foo_json;application&v=1 https://v1.api.puglovers.com/
  • 108. Versionamento - Estratégias REST API! VX Cliente ! 1 Cliente ! 2 Cliente ! n…
  • 109. Versionamento - Estratégias REST API! V1 Cliente ! 1 … REST API! V2 Cliente ! 1 REST API! Vn Cliente ! n
  • 110. Versionamento - Estratégias REST API! V1 Cliente ! 1 … REST API! V2 Cliente ! 1 REST API! Vn Cliente ! n
  • 111. http://www.infoq.com/news/2013/12/api-versioning
  • 112. HREFs
  • 113. HREFs Hypermedia distribuída Todo recurso tem uma URL única Pré-requisito para HATEOAS (linking)
  • 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. 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. Paginação
  • 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. { "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. Representações parciais
  • 120. Gets Parciais http GET http://localhost:8080/pugs/1?fields=name,peso Accept:application/json { "name": "Dorinha", "peso": 10 }
  • 121. Erros
  • 122. Erros Os mais descritivos possível Com o maior número de informações possível
  • 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. IDs
  • 125. IDs Não devem ser sequenciais Únicos globalmente
  • 126. Segurança
  • 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. Media Types
  • 129. Media Type Especificação de Formato Request: Accept Header Response: Content-Type header Content-Type: application/xml Accept: application/json
  • 130. Caching
  • 131. HTTP CachingLocal Cache “The Proxies” Translation Proxy Reverse Proxy Web Server
  • 132. HTTPCaching features allowed (or not) expiration intermediary caches allowed (or not) validation storable(or not)
  • 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. 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. 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. http GET http://localhost:8080/pugs/1
  • 137. Concorrência
  • 138. PUT Condicional 412 Precondition Failed caso ETag não for a mais recente do servidor
  • 139. Mas e se…
  • 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. E para transferir entre duas contas? saldo=100 saldo=80 PUT (saldo - valor) PUT (saldo + valor) http://banco.com.br/contas/id
  • 142. Transações Distribuídas
  • 143. Você não quer transações em HTTP
  • 144. E como resolvo? saldo=100 saldo=80 PUT (saldo - valor) PUT (saldo + valor) http://banco.com.br/contas/id
  • 145. Mapeie em recursos Conta1! saldo=120! Conta2! saldo=80 PUT Conta1(saldo - valor) Conta2(saldo + valor) http://banco.com.br/transferencia/id
  • 146. Isto resolve tudo?
  • 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. Transações Distribuídas
  • 149. Você não quer transações em HTTP
  • 150. Você não consegue fazer transações sobre HTTP
  • 151. Restrições Interoperabilidade Sem mudanças e extensões no HTTP (verbos adicionais, headers especiais)
  • 152. Restrições Baixo acoplamento Os serviços não devem saber que estão em contexto transacional
  • 153. Transações Compensatórias
  • 154. Try Confirm Cancel
  • 155. Estado Inicial Try Confirm Cancel Estado Reservado Estado Final Timeout/Cancel TRY CONFIRM
  • 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. TCC Try: reserve Confirm: pague Cancel: libere
  • 158. "Distributed Transactions Are Evil" http://c2.com/cgi/wiki?DistributedTransactionsAreEvil
  • 159. "I consider "rest transaction" to be an oxymoron.” Roy Fielding https://groups.yahoo.com/neo/groups/rest-discuss/ conversations/topics/12837
  • 160. (quase) Não existem Transações Distribuídas Eder Ignatowicz
  • 161. HATEOAS
  • 162. ESTADO ESTADOESTADO ESTADOESTADO http://uri Transição Transição Transição Transição
  • 163. ESTADO ESTADO Transição ESTADO Transição
  • 164. pug/1 father(?) father ? mother pic
  • 165. Assync
  • 166. Service PUT http://puglovers.com/report/id Client 202 Accepted
  • 167. Service PUT http://puglovers.com/report/id Client 202 Accepted Callback
  • 168. Manutenção
  • 169. Service GET http:///id Client 301 / 303 Service GET
  • 170. Documentação
  • 171. https://helloreverb.com/developers/swagger http://petstore.swagger.wordnik.com/#!/pet Swagger
  • 172. Alternativas a REST APIs
  • 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. SDKs SKDs específicas acabam virando RPC
  • 175. Protocolos Binários Otimização de Transferência de Mensagens Apache Thrift -> Facebook Google Protocol Buffers -> Google APIs Apache Avro -> Hadoop
  • 176. Orquestração / Experience APIS Granuralidade de recursos nem sempre é uma vantagem Pode significar muitos requests
  • 177. "The future of API design: The orchestration layer" Daniel Jacobson - Diretor de Engenharia Netflix Estudo de Caso
  • 178. APIs: large set of unknown developers (LSUDs)
  • 179. Desafios
  • 180. Desafios Diminuir número de “conversas” Mitigar riscos de deploy Suportar várias linguagens Distribuir operações
  • 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. 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. API REST Melhores Práticas
  • 184. Piores Práticas em APIs
  • 185. O que faz uma API horrível? Achar que teu framework MVC vai ter dar uma boa API REST
  • 186. O que faz uma API horrível? Não usar HTTP corretamente
  • 187. O que faz uma API horrível? Documentação ruim
  • 188. O que faz uma API horrível? Suporte inadequado
  • 189. O que faz uma API horrível? Não dar apoio aos desenvolvedores
  • 190. O que faz uma API horrível? Media Types Confusos
  • 191. O que faz uma API horrível? Complexidade na gestão de segurança
  • 192. Pra onde eu vou?
  • 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. REST é tudo isto?
  • 195. NOSSOS SONHOS NA INTEGRAÇÃO DESISTEMAS ESCALABILIDADE SEGURANÇA BAIXO ACOPLAMENTO TOLERÂNCIA A FALHAS Foco no end-user
  • 196. CACHE HATEOAS HTTP tunning
  • 197. HYPERMEDIA
  • 198. Obrigado :)
  • 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