Representational State Transfer (REST)

PROYECTO FIN DE CARRERA:

Tutor: Antonio J. Sierra Collado Alumno: Alberto Cubo Velzquez

NDICE
1. INTRODUCCIN
2. HTTP, URI, XML 3. SOAP Y WSDL 4. REST 5. DEBATE REST-SOAP 6. IMPLEMENTACIONES REST 7. FUTURO DE REST

1. INTRODUCCIN

INTRODUCCIN
Necesidad de realizar tareas en menor tiempo

Internet y Servicios Web como solucin

SERVICIOS WEB:

Facilitan tareas a los usuarios

Ligadas al mundo Web (Internet) Datan de las ltimas dos dcadas 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 Descripcin y estructurado de datos: XML

3. SOAP Y WSDL

CARACTERSTICAS DE SOAP:

Arquitectura de Servicios Web

Creado por IBM, Microsoft y actualmente W3C Basada en RPC Intercambio de informacin entre dos puntos mediante XML Uso de HTTP como tnel 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

CARACTERSTICAS

Origen Roy Thomas Fielding, mbito acadmico Estilo de arquitectura

Describe como debera 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 caractersticas 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

RESTRICCIN 2: SIN ESTADO

RESTRICCIN 3: CACH

RESTRICCIN 4: SISTEMA DE CAPAS

RESTRICCIN 5: INTERFAZ UNIFORME

La implementacin se separa del servicio que proporciona.

Mecanismos para conseguirlo:
Recursos e identificacin de recursos
Manipulacin de recursos a travs de sus representaciones Mensajes Auto-descriptivos Hipermedios como el motor de estado de la aplicacin

RECURSOS
REST es orientado a recursos y no a mtodos

IDENTIFICACIN DE RECURSOS
URI Fsica

URI Lgica

MANIPULACIN DE RECURSOS

Un cliente manipula la representacin de un recurso en vez de su implementacin.

MENSAJES AUTO-DESCRIPTIVOS

Toda la informacin necesaria para procesar el mensaje se encuentra en el propio mensaje. Usa HTTP como protocolo de aplicacin.

HIPERMEDIO COMO EL MOTOR DE ESTADO

MTODOS DE REST

Usa los mtodos de HTTP

Cumple con la restriccin 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 mtodos HTTP

5. DEBATE REST-SOAP

DEBATE REST-SOAP

Inicio junto con la disertacin de Roy Fielding

Los adeptos a REST buscan los puntos dbiles de SOAP

A veces toma un tono poltico al unir SOAP con Microsoft

Principales autores: Paul Prescod, Tim Bray, Robert McMillan, Sam Ruby

DIFERENCIAS ENTRE REST Y SOAP

SOAP
Origen en el mbito acadmico Orientado a RPC

REST
Origen en el mbito de las empresas Orientado a recursos

Servidor almacena parte del estado

El estado se mantiene slo en el cliente, y no se permiten las sesiones

Propone HTTP como nivel de aplicacin

Usa HTTP como tnel para el paso de mensajes

CRTICAS 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 tnel SOAP no puede hacer uso de los mecanismos Cach

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

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 mtodos de bsqueda

API disponible en associates.amazon.com

Posible carencia, si realiza servicios ms sofisticados puede que deba migrar a SOAP

eBay

Desarroll una API REST en 2004

Consulta de productos a travs del mtodo 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 mtodo con parmetros para invocar un producto

RESTLETS

API desarrollada en 2006

Funcionando aunque en fase de depuracin

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 documentacin

Escasas implementaciones y ejemplos prcticos para acercar REST al programador comn

nica solucin, crear organizacin o entidad que agrupe el disperso y escaso trabajo que existe sobre REST