Hola

Asier Marqués

Simettric, Fundador.

4VisionsManager.com, Socio y director técnico.

Desacoplar el cliente del backend

• Mayor escalabilidad

• Separación de problemas

• División de especialidades

• API uniforme para todos los clientes

REST

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

Una buena API REST

No tiene estado en el backend.

Está desacoplado del cliente.

Dispone de una interfaz uniforme

(basada en URIs)

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

Recursos, URIs, hypermedia?

REST: Nivel 1

URIs

URI, uniform resource identifier

Identifica un recurso

Pueden identificar un

recurso por nombre

(URN) o por

localización (URL)

Recurso?

Recursos

/users Listado de usuarios

/users/{id} Un usuario

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

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

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

Formatos

No se debería indicar el formato en la

URI, el formato no identifica al recurso

/invoices.html

/invoices.css

/invoices.xml

Para eso está HTTP

Request:

GET accept: text/html /invoices

Response:

200 content-type: text/html

Response:

406 Not Acceptable

REST: Nivel 2

HTTP como framework

HTTP como Framework

• Protocolo de transporte

• Métodos

• Códigos de estado

• Content-Type

• Gestión de versiones

• Cache

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

Métodos

Request: GET /users

Response: 200 content-type:application/json

Request: POST /users

Response: 201 content-type:application/json

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

HTTP: Códigos de estado

HTTP: Content-Type y Accept

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.

HTTP: ETag

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.

REST: Nivel 3

Hypermedia

Hypermedia?

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

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

Hypermedia

¿Content-Type: text/xml?

Hypermedia

Content-Type: text/xml

Content-Type:

application/servicio+xml

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

Herramientas

Curl

RestClient

Swagger UI (swagger.wordnik.com)

Servicios

3scale.com

apigee.com

Crear un Framework REST

Puntos clave de un framework

• Facilitarnos el trabajo

• Definir una forma de trabajo común

• Reducir tareas repetitivas

Symfony2 Components

HTTP Foundation

Routing

ClassLoader

Console

HTTP Foundation

• Se basa en dos objetos: Request y

Response

• Nos aisla de variables de entorno,

servidor, headers…

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.

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

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

Crear un framework REST

• Eventos

• Permitir extensibilidad

• Configuraciones, diferentes entornos

• Logs y gestión de excepciones

Crear un framework REST

• Sólo lo estrictamente necesario en el

core

• Documentación

• Cobertura de tests

• Aprende de otros

C

O

N

V

E

N

C

I

Ó

N

Documentación

Gracias :)

@asiermarques