Arquitectura REST
Grupo de Construcción de Sw
1
Referencias
http://www.infoq.com/resource/minibooks/emag-
03-2010-rest/en/pdf/ResteMag.pdf
https://www.ics.uci.edu/~fielding/pubs/dissertatio
n/fielding_dissertation.pdf
http://www.xfront.com/REST-Web-Services.html
http://www.vinaysahni.com/best-practices-for-a-
pragmatic-restful-api#requirements
http://www.restapitutorial.com/
2
Qué es REST?
Roy Fielding acuñó el término REST en su
tesis doctoral en el 200:
REST = Representational State Transfer
REST es un estilo arquitectural
HTTP Rest es una forma de implementarlo
3
La web
Request En los sitios
hay recursos
Response que son
accedidos
utilizando una
url que los
identifica de
manera única y
aa través del
protocolo HTTP
5
Request
Response
6
7
Elementos
Lo más importante: recursos
10
Elementos
Lo más importante: recursos
Pueden tener
distintas
representaciones
Se pueden
localizar de
manera única
11
Elementos
Lo más importante: recursos
Pueden tener
distintas
representaciones
Se pueden
localizar de
manera única
http://example.com/customers/1234
http://example.com/orders/2007/10/776654
http://example.com/products/4554
12
Operaciones
Transferir una representación del recurso de
un lado para otro en la red
Modificar un recurso o Crear un recurso
Las operaciones son sin estado (no se sabe
qué pasó antes)
13
Principios de diseño REST
Identificar las entidades conceptuales que se
quieren exhibir como servicios
Crear una URL para cada recurso. Los
recursos son sustantivos NO VERBOS
Ejemplo de una mala definición:
http://www.parts-depot.com/parts/getPart?id=00345
Corrección:
http://www.parts-depot.com/parts/00345
14
Principios de diseño REST
Categorizar los recursos de acuerdo con:
El cliente recibirá una representación del recurso
(HTTP GET)
El cliente modificará o creará el recurso (HTTP
POST, PUT, y/o DELETE).
Todos los recursos que se accedan vía
HTTP GET no deben tener efecto de borde
(solo trae una representación del recurso) .
15
Principios de diseño REST
Los recursos deben encadenar otros
recursos: proveer hyperlinks para obtener
más detalles
16
Método URI Acción Parámetros Cuerpo Retorno
@QueryParam page: página
a consultar
@QueryParam Colección de objetos
maxRecords: cantidad de JSON Book y el total
Obtener todos los objetos registros a consultar de registros en la
GET /books
JSON de Book (RETRIEVE) base de datos en el
Si se omite alguno de estos header X-Total-
parámetros se obtiene todos Count
los registros en la base de
datos
Obtener los atributos de una Objeto JSON con
@PathParam id:
GET /books/:id instancia de Book en formato detalle de la
Identificador del registro
JSON(RETRIEVE) instancia de Book
Objeto
Crear una nueva instancia de la JSON de Objeto JSON de
POST /books
entidad Book (CREATE) Book a Book creado
crear
Objeto
Actualiza una instancia de la @PathParam id: Objeto JSON de
PUT /books/:id JSON de
entidad Book (UPDATE) Identificador del registro Book actualizado
Book
Borra instancia de Book en el @PathParam id:
DELETE /books/:id
servidor (DELETE) Identificador del registro
17
Diseño de un API Rest
Pensar en las entidades principales de la
aplicación como colecciones de recursos.
/products
/customers
/orders
18
Diseño de un API Rest
Sobre una colección se puede traer todos los
elementos de la colección, traer un elemento
particular, agregar un elemento particular,
Borrar un elemento.
Los elementos en las colecciones deben
tener una representación.
19
Nombramiento de los recursos
Los APIs REST se escriben para los clientes
que van a consumir los servicios.
El nombre y la estructura de los URIs deben
transmitir un significado claro y no ambiguo a
esos consumidores.
Diseñar para sus clientes, no para sus datos.
Tomado de: http://www.restapitutorial.com/lessons/restfulresourcenaming.html
20
Nombramiento de los recursos
Requerimientos:
1. Dentro de un conjunto de servicios, cada
recurso debe tener al menos un URI que lo
identifique.
2. El URI debe tener sentido y describir
adecuadamente el recurso.
3. Los URIs debe seguir una estructura predecible,
jerárquica para mejorar el entendimiento y
facilitar su uso.
Tomado de: http://www.restapitutorial.com/lessons/restfulresourcenaming.html
21
Nombramiento de los recursos
5. Deber ser predecible en el sentido de que son
coherentes
6. Debe ser jerárquica en el sentido de que la
estructura de los datos tiene relaciones.
7. Esta no es una regla REST o restricción, pero
mejora la API.
Tomado de: http://www.restapitutorial.com/lessons/restfulresourcenaming.html
22
URI Significado
/customers La colección de recursos de tipo
Customer.
/customers/33452/ El Customer 33452
/orders La colección de todas las ordenes en
el sistema
/orders/1234 La Orden 1234
/customers/33452/orders La colección de todas las ordenes del
Customer 33452
/orders/1234/items La colección de todos los Item de la
Orden 1234
La clase System se utiliza para poder nombrar las colecciones que pueden ser
accedidas de forma directa
23
Método Significado
GET /customers Retorna la colección de recursos de tipo Customer.
POST /customers Crea un nuevo Customer
PUT /customers No se usa
DELETE /customers No se usa
GET /customers/33452/ Retorna el Customer 33452
GET|PUT|DELETE /customers/33452/ Crea, actualiza o elimina el Customer 33452
POST /customers/33452/ No se usa
GET /customers/33452/orders La colección de todas las ordenes del Customer 33452
POST /customers/33452/orders Crea una nueva Order para el Customer 33452
GET /customers/33452/orders/1234 Retorna la Order 1234 del Customer 3452
24
Recursos y representaciones
GET /curstomers/:id_customer
Devuelve la
representación del
recurso customer
identificado por el
id_customer
Representación JSON
25
Recursos y representaciones
GET /customers
Devuelve un arreglo de
representaciones del
recurso customer
26
Recursos y representaciones
DELETE /curstomers/:id_customer
Borra el recurso
customer identificado por
el id_customer
27
Recursos y representaciones
POST /curstomers
Parámetro: {“firstName”:“Juan”,
“lastName”: “Perez”,
”age”:30}
Crea un nuevo recurso
customer, con la
información pasada por
parámetro y regresa el id
correspondiente
28
