Representational State
Transfer (REST)
PROYECTO FIN DE CARRERA:
Tutor: Antonio J. Sierra Collado
Alumno: Alberto Cubo Velázquez
ÍNDICE
1. INTRODUCCIÓN
2. HTTP, URI, XML
3. SOAP Y WSDL
4. REST
5. DEBATE REST-SOAP
6. IMPLEMENTACIONES REST
7. FUTURO DE REST
1. INTRODUCCIÓN
INTRODUCCIÓN
■ Necesidad de realizar tareas en menor tiempo

Internet y Servicios Web como solución
SERVICIOS WEB:

Facilitan tareas a los usuarios

Ligadas al mundo Web (Internet)

Datan de las últimas dos décadas

Origen: CORBA, RPC

Actualmente SOAP tiene el monopolio

REST como alternativa a SOAP
IMPORTANCIA DE REST EN LA WEB
2. URI, HTTP Y XML
URI, HTTP, XML
Bases para construir Servicios Web:

Identificador de recursos: URI, UUID

Protocolo de Transferencia: HTTP

Descripción y estructurado de datos: XML
3. SOAP Y WSDL
CARACTERÍSTICAS DE SOAP:

Arquitectura de Servicios Web

Creado por IBM, Microsoft y actualmente W3C

Basada en RPC

Intercambio de información entre dos puntos mediante XML

Uso de HTTP como túnel para las comunicaciones

Descubrimiento de Servicios mediante WSDL
FUNCIONAMIENTO DE SOAP:
MENSAJES SOAP:
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP- ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<getQuote xmlns= "http://namespaces.alberto.org/xmljava/ch2/">
<symbol>RHAT</symbol>
</getQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
4. REST
CARACTERÍSTICAS

Origen Roy Thomas Fielding, ámbito académico

Estilo de arquitectura

Describe como debería comportarse la Web

Se apoya en el uso de URI y HTTP

REST evoluciona en la red
ESTILO DE ARQUITECTURA:
 Conjunto coordinado de restricciones que controlan el funcionamiento y características
de los elementos de la arquitectura y permite las relaciones de unos con otros.
RESTRICCIONES DE REST:

Cliente Servidor

Sin estado

Caché

Sistema de capas

Interfaz Uniforme
RESTRICCION 1: CLIENTE-SERVIDOR
RESTRICCIÓN 2: SIN ESTADO
RESTRICCIÓN 3: CACHÉ
RESTRICCIÓN 4: SISTEMA DE CAPAS
RESTRICCIÓN 5: INTERFAZ UNIFORME

La implementación se separa del servicio que proporciona.

Mecanismos para conseguirlo:
 Recursos e identificación de recursos
 Manipulación de recursos a través de sus representaciones
 Mensajes Auto-descriptivos
 Hipermedios como el motor de estado de la aplicación
RECURSOS
• REST es orientado a recursos y no a métodos
IDENTIFICACIÓN DE RECURSOS
• URI Física
• URI Lógica
MANIPULACIÓN DE RECURSOS

Un cliente manipula la representación de un recurso en vez de su
implementación.
MENSAJES AUTO-DESCRIPTIVOS

Toda la información necesaria para procesar el mensaje se encuentra en
el propio mensaje.

Usa HTTP como protocolo de aplicación.
HIPERMEDIO COMO EL MOTOR DE ESTADO
MÉTODOS DE REST

Usa los métodos de HTTP

Cumple con la restricción de interfaz uniforme
BENEFICIOS OBTENIDOS AL USAR REST

Mejora el tiempo de respuesta gracias al mecanismo Caché y los
mensajes auto-descriptivos

Mejora la seguridad debido a los mensajes auto-descriptivos y el
uso de los métodos HTTP
5. DEBATE REST-SOAP
DEBATE REST-SOAP

Inicio junto con la disertación de Roy Fielding

Los adeptos a REST buscan los puntos débiles de SOAP

A veces toma un tono político al unir SOAP con Microsoft

Principales autores: Paul Prescod, Tim Bray, Robert McMillan, Sam
Ruby…
DIFERENCIAS ENTRE REST Y SOAP
SOAP
REST
Origen en el ámbito académico
Origen en el ámbito de las empresas
Orientado a RPC
Orientado a recursos
Servidor almacena parte del estado
El estado se mantiene sólo en el cliente, y
no se permiten las sesiones
Usa HTTP como túnel para el paso de
mensajes
Propone HTTP como nivel de aplicación
CRÍTICAS DE REST HACIA SOAP

SOAP no es transparente, apuesta por el encapsulamiento

SOAP no dispone de un sistema de direccionamiento global

SOAP puede derivar en agujeros de seguridad

SOAP no aprovecha muchas de las ventajas de HTTP al usarlo
solamente como túnel

SOAP no puede hacer uso de los mecanismos Caché
CRÍTICAS DE SOAP HACIA REST

REST es poco flexible

REST no está preparado para albergar Servicios Web de gran
complejidad como las aplicaciones B2B

REST falla a la hora de realizar Servicios Web que necesiten
procesado de datos

REST tiene grandes problemas de seguridad al no soportar el
concepto de sesión
6. IMPLEMENTACIONES
AMAZON

Pionera en el uso de REST en 2002, muy comentado en la Web

Base de datos con todos los productos que vende

Los productos se acceden como recursos, no como métodos de
búsqueda

API disponible en associates.amazon.com

Posible carencia, si realiza servicios más sofisticados puede que
deba migrar a SOAP
eBay

Desarrolló una API REST en 2004

Consulta de productos a través del método GetSearchResults()

Ejemplo de uso:
http://rest.api.ebay.com/restapi?CallName=GetSearchResults&RequestTo
ken =xyz123&RequestUserId=ebayuser&Query=toy%20boat&Schema=1

Fallo, usa un método con parámetros para invocar un producto
RESTLETS

API desarrollada en 2006

Funcionando aunque en fase de depuración

Acerca REST a los desarrolladores Java

Realiza las mismas funciones de los Servlets pero al estilo REST
7. FUTURO DE REST
FUTURO DE REST

SOAP mantiene el monopolio de los Servicios Web

Carencia de documentación

Escasas implementaciones y ejemplos prácticos para acercar REST
al programador común

Única solución, crear organización o entidad que agrupe el disperso
y escaso trabajo que existe sobre REST
Descargar

Representational State Transfer (REST)