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

■ Necesidad de realizar tareas en menor tiempo

Internet y Servicios Web como solución

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

Identificador de recursos: URI, UUID

Protocolo de Transferencia: HTTP

Descripción y estructurado de datos: XML

Bases para construir Servicios Web:

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&RequestToken =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