3. Hola
Asier Marqués
Simettric, Fundador.
4VisionsManager.com, Socio y director técnico.

4. Desacoplar el cliente del backend
• Mayor escalabilidad
• Separación de problemas
• División de especialidades
• API uniforme para todos los clientes

5. REST

6. REST
REpresentational State Transfer
Un estilo de arquitectura para
desarrollar aplicaciones web distribuidas
que se basa en el uso del protocolo
HTTP e Hypermedia.
Definido en el 2000 por Roy Fielding

7. Una buena API REST
No tiene estado en el backend.
Está desacoplado del cliente.
Dispone de una interfaz uniforme
(basada en URIs)

8. 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

9. Recursos, URIs, hypermedia?

10. REST: Nivel 1
URIs

11. URI, uniform resource identifier
Identifica un recurso
Pueden identificar un
recurso por nombre
(URN) o por
localización (URL)

12. Recurso?

13. Recursos
/users Listado de usuarios
/users/{id} Un usuario

14. 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

15. URIs incorrectas
Nunca se usan verbos
/getUser/{id}
/users/{id}/edit
/login
Deben ser jerárquicas
/invoices/user/{id}
Identifican un recurso
/invoices/page/2

16. URIs válidas
Nunca se usan verbos
/users/{id}
/users/{id}
/access-token
Deben ser jerárquicas
/user/{id}/invoices
Identifican un recurso
/invoices/?page=2

17. Formatos
No se debería indicar el formato en la
URI, el formato no identifica al recurso
/invoices.html
/invoices.css
/invoices.xml

18. Para eso está HTTP
Request:
GET accept: text/html /invoices
Response:
200 content-type: text/html
Response:
406 Not Acceptable

19. REST: Nivel 2
HTTP
como framework

20. HTTP como Framework
• Protocolo de transporte
• Métodos
• Códigos de estado
• Content-Type
• Gestión de versiones
• Cache

21. HTTP: Métodos
GET Recupera el recurso
POST Crea un nuevo recurso
PUT Edita el recurso
POST/PATCH Edita el recurso parcialmente
DELETE Elimina el recurso

22. Métodos
Request: GET /users
Response: 200 content-type:application/json
Request: POST /users
Response: 201 content-type:application/json

23. Métodos
Request: GET /users/11
Response: 200 content-type:application/json
Request: PUT /users/11
Response: 200 content-type:application/json
Request: DELETE /users/11
Response: 204 no content

24. HTTP: Códigos de estado

26. HTTP: Content-Type y Accept

27. 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.

28. HTTP: ETag

29. 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.

30. REST: Nivel 3
Hypermedia

31. Hypermedia?

32. 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

33. <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>

34. Hypermedia
¿Content-Type: text/xml?

35. Hypermedia
Content-Type: text/xml
Content-Type:
application/servicio+xml

36. 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

37. Herramientas
Curl
RestClient
Swagger UI (swagger.wordnik.com)

38. Servicios
3scale.com
apigee.com

39. Crear un Framework REST

40. Puntos clave de un framework
• Facilitarnos el trabajo
• Definir una forma de trabajo común
• Reducir tareas repetitivas

41. Symfony2 Components
HTTP Foundation
Routing
ClassLoader
Console

42. HTTP Foundation
• Se basa en dos objetos: Request y
Response
• Nos aisla de variables de entorno,
servidor, headers…

43. 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.

44. 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

45. 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

46. Crear un framework REST
• Eventos
• Permitir extensibilidad
• Configuraciones, diferentes entornos
• Logs y gestión de excepciones

47. Crear un framework REST
• Sólo lo estrictamente necesario en el
core
• Documentación
• Cobertura de tests
• Aprende de otros

48. C
O
N
V
E
N
C
I
Ó
N

51. Documentación

52. Gracias :)
@asiermarques