REST - deSymfony2012
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

REST - deSymfony2012

  • 7,869 views
Uploaded on

Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.

Repasaremos conceptos y principios para que una arquitectura sea RESTfull, se explicará cómo se ha plateado el framework Leophard para seguir estos y otros principios.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,869
On Slideshare
3,050
From Embeds
4,819
Number of Embeds
33

Actions

Shares
Downloads
93
Comments
0
Likes
4

Embeds 4,819

http://www.symfony.es 1,680
http://magdkudama.com 831
http://blog.liip.ch 705
http://desymfony.com 521
http://symfony.es 487
https://blog.liip.ch 225
http://feeds.feedburner.com 102
http://www.webcomparte.cl 66
http://www.desymfony.com 48
http://desymfony.es 33
http://asier.sp.in 23
http://blog.local 19
http://librosweb.es 18
http://speakerin.com 15
http://192.168.11.11 6
https://twimg0-a.akamaihd.net 6
http://www.aggregator.ch 4
https://si0.twimg.com 4
http://192.168.11.10 3
http://5.135.163.193 3
http://www.newsblur.com 3
http://desymfony.acilia.es 3
http://www.sfexception.com 2
http://www.desymfony.es 2
http://www.magdkudama.com 2
http://translate.googleusercontent.com 1
http://www.speakerin.com 1
https://www.linkedin.com 1
http://www.linkedin.com 1
http://ranksit.com 1
http://symfony.local 1
http://desymfony.local 1
http://tech.local 1

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. HolaAsier MarquésSimettric, Fundador.4VisionsManager.com, Socio y director técnico.
  • 2. Desacoplar el cliente del backend• Mayor escalabilidad• Separación de problemas• División de especialidades• API uniforme para todos los clientes
  • 3. REST
  • 4. RESTREpresentational State TransferUn estilo de arquitectura paradesarrollar aplicaciones web distribuidasque se basa en el uso del protocoloHTTP e Hypermedia.Definido en el 2000 por Roy Fielding
  • 5. Una buena API RESTNo tiene estado en el backend.Está desacoplado del cliente.Dispone de una interfaz uniforme(basada en URIs)
  • 6. Richardson Maturity Model# Nivel 1 (Pobre): Se usan URIs para identificar recursos# Nivel 2 (Medio): Se usa el protocolo HTTP adecuadamente# Nivel 3 (Óptimo): Se implementa hypermedia.http://www.crummy.com/writing/speaking/2008-QCon/act3.html
  • 7. Recursos, URIs, hypermedia?
  • 8. REST: Nivel 1URIs
  • 9. URI, uniform resource identifier Identifica un recurso Pueden identificar un recurso por nombre (URN) o por localización (URL)
  • 10. Recurso?
  • 11. Recursos/users Listado de usuarios/users/{id} Un usuario
  • 12. Reglas para identificar recursos• Se debe *identificar* un recurso!• Las URIs se construyen con nombres nunca con verbos• Deberían tener una estructura jerárquica
  • 13. URIs incorrectasNunca se usan verbos/getUser/{id}/users/{id}/edit/loginDeben ser jerárquicas/invoices/user/{id}Identifican un recurso/invoices/page/2
  • 14. URIs válidasNunca se usan verbos/users/{id}/users/{id}/access-tokenDeben ser jerárquicas/user/{id}/invoicesIdentifican un recurso/invoices/?page=2
  • 15. FormatosNo se debería indicar el formato en laURI, el formato no identifica al recurso/invoices.html/invoices.css/invoices.xml
  • 16. Para eso está HTTPRequest:GET accept: text/html /invoicesResponse:200 content-type: text/htmlResponse:406 Not Acceptable
  • 17. REST: Nivel 2HTTPcomo framework
  • 18. HTTP como Framework• Protocolo de transporte• Métodos• Códigos de estado• Content-Type• Gestión de versiones• Cache
  • 19. HTTP: MétodosGET Recupera el recursoPOST Crea un nuevo recursoPUT Edita el recursoPOST/PATCH Edita el recurso parcialmenteDELETE Elimina el recurso
  • 20. MétodosRequest: GET /usersResponse: 200 content-type:application/jsonRequest: POST /usersResponse: 201 content-type:application/json
  • 21. MétodosRequest: GET /users/11Response: 200 content-type:application/jsonRequest: PUT /users/11Response: 200 content-type:application/jsonRequest: DELETE /users/11Response: 204 no content
  • 22. HTTP: Códigos de estado
  • 23. HTTP: Content-Type y Accept
  • 24. Content-Type y Accept• Content-Type nos dice qué tipo de representación tiene el recurso al que estamos accediendo.• Con Accept le decimos qué tipo de representación queremos.
  • 25. HTTP: ETag
  • 26. HTTP: Etag y Last-Modified• Con Etag podemos controlar si el recurso se ha modificado desde la última vez que accedimos con un hash.• If-None-Match se encarga de indicar que la petición sea efectiva siempre y cuando el eTag sea distinto, If-Match hace lo inverso.• Last-Modified/If-Modified-Since permiten saber si un recurso se ha modificado en base a una fecha.
  • 27. REST: Nivel 3Hypermedia
  • 28. Hypermedia?
  • 29. Hypermedia• Se basa en la idea de enlazar recursos.• Para que sea útil, el cliente debe saber que en la respuesta hay contenido hypermedia.• En content-type es clave para esto
  • 30. <bill rel=“http://api.servicio.com/doc/order”> <id>666</id> <currency>EUR</currency> <items>..</items> <amount>67</amount> <status>UNPAID</status> <links> <link rel=“payment”> http://api.servicio.com/order/666/payment </link> <link rel=“cancel”> http://api.servicio.com/order/666/cancelation </link> </links></bill>
  • 31. Hypermedia¿Content-Type: text/xml?
  • 32. Hypermedia Content-Type: text/xml Content-Type:application/servicio+xml
  • 33. RFC4627 JSON Hypertext Application Language Content-Type: application/hal+json { "_links": { "self": {"href": "/orders/523" }, "warehouse": {"href": "/warehouse/56" }, " invoice": {"href": "/invoices/873“} }, "currency": "USD", "status": "shipped", "total": 10.20 }http://tools.ietf.org/html/draft-kelly-json-hal-00
  • 34. HerramientasCurlRestClientSwagger UI (swagger.wordnik.com)
  • 35. Servicios3scale.comapigee.com
  • 36. Crear un Framework REST
  • 37. Puntos clave de un framework• Facilitarnos el trabajo• Definir una forma de trabajo común• Reducir tareas repetitivas
  • 38. Symfony2 ComponentsHTTP FoundationRoutingClassLoaderConsole
  • 39. HTTP Foundation• Se basa en dos objetos: Request y Response• Nos aisla de variables de entorno, servidor, headers…
  • 40. Routing• Podemos definir URIs mediante patrones• Requisitos en las URIs de métodos HTTP y parámetros.• Varios tipos de Matcher para identificar la URI actual.
  • 41. Console• Nos permite crear comandos para shell• Cada comando es una clase, permite definir parámetros, atributos para el comando• Los menús se generan de forma automática
  • 42. Crear un framework REST• Crearlo sobre una aplicación real• Utilizar el componente Console para automatizar tareas repetitivas• Pensar en la organización del código
  • 43. Crear un framework REST• Eventos• Permitir extensibilidad• Configuraciones, diferentes entornos• Logs y gestión de excepciones
  • 44. Crear un framework REST• Sólo lo estrictamente necesario en el core• Documentación• Cobertura de tests• Aprende de otros
  • 45. CONVENCIÓN
  • 46. Documentación
  • 47. Gracias :)@asiermarques