Rest

REST: Un estilo arquitectnico para la WWW
Arquitectura de la WWW y el Estilo Arquitectnico REST: Arquitecturas RESTful y Arquitecturas Orientadas a Recursos
Dr. Javier Soriano

Universidad Politcnica de Madrid (UPM) Web: http://conwet.fi.upm.es
Qu es REST? Origenes
!! !! !!
Representational State Transfer Trmino con el que Roy T. Fielding (URI, HTTP/ 1.1) denomina al estilo arquitectnico que presenta en su Tesis Doctoral titulada Architectural Styles and the Design of Networkbased Software Architectures (UC Irvine, 2000)
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Qu no es REST?
!!
REST NO es:
"! "! "! "! "!
Un protocolo Una arquitectura software Un producto software Un estndar Un nombre extravagante para denotar a los Servicios Web
!!
REST ha pasado a ser un buzzword (palabra de moda, utilizada de manera vaga e imprecisa por una audiencia no especializada) Roy Fielding will officially disown most of the RESTful authors and software packages available. Nobody will care, or worse, somebody looking to make a name for themselves will proclaim that Roy doesn't really understand REST, and they'll be right: Roy doesn't understand what they consider to be REST, and the fact that he created the term will be of no importance anymore. Being "REST"ful will equate to "I did it myself!", complete with expectations of a gold star and a lollipop.
http://dotnet.dzone.com/articles/ted-neward-2009-predictions-20
Qu es REST? Arquitectura Vs. Estilo Arquitectnico
RoyT.Fielding http://roy.gbiv.com/untangled/2008/on-software-architecture
Qu es REST? Arquitectura Vs. Estilo Arquitectnico

!!
!!
!!
Una arquitectura software define una abstracin de los elementos de tiempo de ejecucin de un sistema software durante alguna fase de su operacin [en trminos de componentes e interrelaciones entre estos]. Un sistema puede componerse de distintos niveles de abstraccin [y de diferentes granularidades de componentes] y de diferentes fases de operacin, cada una con su propia arquitectura Un estilo arquitectnico software es un conjunto [nombrado] de restricciones sobre la interaccin de diferentes componentes que, cuando se respeta, dota a la arquitectura resultante de determinadas propiedades [deseables] La arquitectura es por tanto una abstraccin de la implementacin del sistema, y los estilos son los patrones con nombre mediante los cuales podemos comprender mejor la arquitectura y el diseo arquitectnico
RoyT.Fielding http://roy.gbiv.com/untangled/2008/on-software-architecture
Qu es REST?... En el contexto de la arquitectura de la WWW

!!
Propsito de REST:
la motivacin para desarrollar REST fue crear un modelo arquitectnico de cmo debera funcionar la Web, que pudiese servir como marco de trabajo que guiase la creacin de estndares de protocolos Web
http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm

!!
!!
!!
Implementacin de la Web: universo actual de informacin identificada mediante URIs y de todas las versiones especficas de software que opera en ese espacio de informacin (Safari, Firefox, Chrome, Apache httpd, WordPress, etc.) Arquitectura de la Web: conjunto de protocolos y formatos de datos que definen la sintaxis y la semntica de las diferentes interacciones que se produden entre los componentes Web, incluidos los estndares para URI, HTTP, HTML, XML, y muchos otros. Todos ellos se han diseado para optimizar las interacciones RESTful, con diferentes niveles de xito, pero NO para requerir esas interacciones puesto que stas no son la nica forma en que se usan REST: estilo arquitectnico que, cuando se sigue, permite a los componentes realizar sus funciones maximizando las propiedades arquitectnicas ms importantes de un sistema global de informacin basado en red (e.g. maximizar el incremento de la informacin identificada dentro del sistema, con lo que se incrementa la utilidad del sistema en su conjunto)
Architecture of the World Wide Web, Vol. I: http://www.w3.org/TR/webarch/

!!
!!
!!
Slo algunas de las arquitecturas que pueden encontrarse en la Web son RESTful Las arquitecturas RESTful funcionan mejor en la Web que cualquier otra arq. conocida: REST induce las propiedades arquitectnicas ms demandadas por la Web: reutilizacin, escalabilidad anrquica, evolutividad y crecimiento sinergtico La arquitectura de la Web se ha actualizado a lo largo del tiempo para promover REST por encima del resto de estilos arquitectnicos, por diseo
Architecture of the World Wide Web, Vol. I: http://www.w3.org/TR/webarch/
Arquitectura de la WWW
!!
Architecture of the World Wide Web, Vol. 1 (2005)

"!
"! "! "!
W3C crea un Technical Architecture Group para documentar y construir consenso entorno a los principios a los que deberan adherirse todos los componentes de la Web Participan Tim Berners-Lee, Roy T. Fielding Resultado: http://www.w3.org/TR/webarch/ Influenciada notablemente por REST (2000)
!!
Recursos
"!
"!
The great thing about resources is that I went on for years without having to define it [the term resource] Tim Berners-Lee Todo concepto en un dominio puede ser considerado un recurso
!!
Recurso de informacin: aquel cuyas caracteristicas esenciales pueden ser transportadas en un mensaje 1er principio: Un esquema de nombrado global produce efectos de red a nivel global
"!
Identificados biunvocamente mediante la sintaxis URI

!!
!!
Representaciones
"!
"!
"!
"!
Una representacin se define como la codificacin de (cierta) informacin acerca del estado de un recurso Todo recurso (i.e. toda URI) debe tener al menos una representacin proporcionada por su propietario. Una URI sin representacin asociada es un error Toda representacin deber ser tipada. Los protocolos web debern transmitir representaciones como flujos de octetos tipados mediante tipos media de Internet Un recurso puede tener mltiples representaciones, gracias especialmente a la capacidad de negociacin de contenido y a los tipos MIME
!!
Utilizada por menos del 1% de la web
!!
Propiedad de las URIs

"!
"!
Denota quin determina qu recurso identifica una URI determinada, y quin se responsabiliza de proporcionar sus representaciones y su comportamiento ante el interfaz uniforme HTTP Persistencia de una URI: Cool URIs dont change No estn permitidas. Dos recursos diferentes deben tener URIs distintas, incluso si devuelven la misma representacin
!!
!!
Colisiones de URIs
"!
Dos URIs pueden de-referenciar la misma representacin (e.g. URI que denota El tiempo hoy y URI que denota El tiempo en Navidad. Hoy es Navidad)
!!
!!
Identificadores de Fragmentos (elemento sintctico #) Interfaz Uniforme:

"!
Define la sintaxis y la semntica de TODAS las operaciones que pueden realizarse para interactuar con los recursos
"! "! "! "! "! "!
POST GET PUT DELETE HEAD OPTIONS
(Create) (Read) (Uptate) (Delete)
!!
Las claves de la evolucin en la Web son la ortogonalidad y la extensibilidad requerida a sus (futuras) especificaciones
"!
Se define extensibilidad como la propiedad de una tecnologa que promueve su evolucin sin sacrificar por ello la interoperabilidad
!!
Un agente debe especificar cmo se comportar con extensiones que no conozca: bien fallando, bien ignorndolas
"!
Identificacin, interaccin y representacin se muestran como conceptos ortogonales, de modo que sus tecnologas pueden evolucionar de manera independiente
Principales estndares relacionados

!!
HTTP
"!
Pginas dedicadas a HTTP del W3C

!! !!
Pgina de noticias y eventos: http://www.w3.org/Protocols/ Pgina de especificaciones: http://www.w3.org/Protocols/Specs.html
"! "!
HTTP 1.0 nunca lleg a ser un estndar oficial de Internet. El estndar de facto se describe en RFC 1945 HTTP 1.1 ha sido desarrollado de forma abierta por un WG del IETF. El estndar se describe en RFC 2616 (junio 1999) RFC 822 Estructura de los mensajes de texto de Internet, incluidos los campos de cabecera RFC 2396 definicin de URL/URI (sustituye RFC 1738 y RFC 1808) RFC 1521 Definicin del estndar MIME y de los tipos MIME
!!
Otros RFC's tiles:

"! "! "!
Principios RESTful
!!
!!
Mantener sin estado la comunicacin entre cliente y servidor Asignar una URI diferente a cada estado de servidor
"!
Cookies violan REST an no asociar estado entre cliente y servidor mediante la representacin actual devuelta por la URI que estuviera visitando el primero
Flujo de informacin en una aplicacin Complejidad Complejidad Web fortuita esencial

HTTP (REST) OOP RDBMS
HTTP (REST)
RPC
OOP
RDBMS
HTTP (REST)
ROA
RDBMS
HTTP (REST)
ROA
Data
Diseo de un servicio RESTful paso a paso

1.! Todo Recurso debe ser Identificado
"!
Todo Concepto en el Dominio puede ser un Recurso

Tablero Alfil Reina Jugador
Mover
Rey Posicin Torre
Partida Caballo Pen
Leonard Richardson & Sam Ruby RESTful Web Services, OReilly 2007
Diseo de un servicio RESTful paso a paso: Identificacin de recursos

!! !!
Un modelo de recursos identifica y clasifica todos los recursos que el cliente utiliza para interactuar con el servidor Herramientas que ayudan a validar si un servidor implementa correctamente http (e.g. respeta el principio de visibilidad):
"! "! "! "!
Firebug: http://getfirebug.com Yahoo! Yslow: http://developer.yahoo.com/yslow/ Resource Expert Droid: http://redbot.org/ Ninguna de estas herramientas sirve para validar un modelo de recursos. No hay un criterio claro para saber si un modelo de recursos es corecto, aunque s existen estrategias y mejores prcticas

!! !!
Proceso iterativo Puede comenzarse utilizando entidades (nombres) de dominio como base para el diseo, a partir de los casos de uso y de la descripcin del servicio web
"!
Identifique nombres del dominio con los que se pueda interactuar mediante operaciones CRUD
!!
Caso de estudio: Servicio web para gestionar fotografas y vdeos (del estilo de flickr o picassa)

!!
Un mapping directo de entidades de dominio a recursos puede generar recursos ineficientes o difciles de usar mediante el interfaz http
"!
"!
Un mapping directo desde un modelo de datos E/R o un modelo de objetos de una aplicacin puede NO producir los mejores resultados, ya que el criterio de modelado no es el mismo en cada caso Debe derminarse la granularidad de recursos apropiada teniendo en cuenta
!! !! !! !! !!
Comodidad de uso por parte del cliente (patrones de uso) Eficiencia en el uso de la red, latencia Tamao de las representaciones / Posibilidad de ser cacheable Frecuencia de cambio Mutabilidad
"!
Criterio: Eficiencia # Separar los datos ms cacheables, que cambien menos frecuentemente o que sean inmutable de los menos cacheables, que cambian ms frecuentemente o que son mutables

!!
Colecciones
"!
"!
"!
"! "!
Pueden agruparse recursos similares en base a cualquier criterio especfico de la aplicacin (recursos que comparten el mismo schema, un mismo conjunto de atributos o propiedades, etc.) Una coleccin no implica necesariamente una organizacin jerrquica: un recurso puede ser parte de ms de una coleccin Permiten referirse a grupos de recursos como un recurso para realizar consultas sobre la coleccin o para realizar una misma operacin sobre varios recursos al mismo tiempo Permiten utilizar la coleccin como una fbrica para crear nuevos recursos Deber disearse una representacin por cada coleccin con informacin acerca de todos o de parte de sus miembros

!!
Recursos compuestos (composites)

"!
"!
Permiten combinar/agregar mltiples recursos dispares en un nico recurso cuyo estado se compone de los estados de dos o ms recursos Reducen la visibilidad intrnseca al http (producen solape de datos entre recursos) que afectarn al uso de proxies cach

!!
Recursos compuestos (composites)

!!
Soporte para funciones de procesamiento/ computacin

"!
"!
Las restricciones REST encajan ms fcilmente con cosas o entidades en el dominio de la aplicacin. Aun as, deben aplicarse a escenarios que implican funciones de procesamiento (validacin de una tarjeta, clculo de la distancia entre dos lugares, instrucciones de navegacin para ir de un lugar a otro) La funcin de procesamiento debe tratarse/abstraerse como un recurso
!! !!
Los argumentos de entrada a la funcin se proporcionarn mediante parmetros de consulta El resultado de la funcin se obtendr mediante una representacin del recurso (se prefiere GET cuando los mtodos sean seguros e idempotentes)

!!

!!

!!
Uso de controladores para operar atomicamente sobre recursos

"! "! "!
Ayudan a incrementar la separacin de responsabilidades (y a disminuir el acoplamiento) entre clientes y servidores, mejoran la eficiencia de red y permiten a los servidores abstraer e implementar operaciones de negocio complejas y cambios en recursos de manera atmica
!!
Por ejemplo, aquellas que implican la modificacin de ms de un recurso, o cuyo mapping a PUT o DELETE no es obvio
"! "!
Se designar un recurso controlador para cada operacin Se lanzar la operacin mediante un POST
!! !!
Si el resultado de la operacin es la creacin de un nuevo recurso, se devolver 201 (Created) con una cabecera Location conteniendo el URI del nuevo recurso Si el resultado es la modificacin de uno o ms recursos existentes, se devolver 303 (See Other) con una cabecera Location conteniendo la URI que pueden usar los clientes para obtener una representacin de esas modificaciones. Si no puede proporcionarse una nica URI de todos los recursos modificados, se devolver 200 (OK) junto con una representacin en el cuerpo del mensaje que los clientes puedan usar para saber sobre el resultado

!!

"!
Debe evitarse A TODA COSTA el tunneling, i.e. utilizar el mismo mtodo http en una misma URI para diferentes acciones
!!
Reduce la visibilidad a nivel de protocolo (URI, mtodo http, cabeceras y tipos media no identifican sin ambigedad la operacin)
"!
Caso de estudio: Sincronizacin de una agenda de direcciones con un servidor

!! !! !!
Haciendo la sincronizacin en el cliente de un paso Haciendo la sincronizacin en el cliente entrada a entrada Empleando un recurso controlador que haga la sincronizacin en el servidor

!!

2.! Diseo de los URIs
Diseo de un servicio RESTful paso a paso: Diseo de los URIs

/tablero/12345678
/posicion/wqd3,wkd1,bqe6,bkf8
Mover = d3-d8
/posicion/wqd8,wkd1,bqe6,bkf8

!! !!
Un URI es un identificador opaco de recurso

"!
Cada recurso tiene una URI propia, diferente a las del resto de recursos No debe perderse excesivo tiempo en el diseo de las URIs Debe centrarse prioritariamente la consistencia de las URIs
Principios bsicos:
"! "!
!!
Seguir convenciones comunes y mejores prcticas en el diseo de URIs conlleva una serie de ventajas:
"! "! "! "!
Genera URIs ms fciles de depurar y de gestionar Puede centralizarse cdigo para extraer datos de la URI de una peticin Se ahorra tiempo de diseo e implementacin en el procesado de los URIs Si se particionan los URIs de un servidor en dominios, subdominios y caminos (paths) se consigue mayor flexibilidad operacional para distribuir carga, monitorizar, encaminar y securizar la solucin

!!
Convenciones
"!
Dominios y subdominios: Utilice dominios y subdominios para agrupar o particionar a nivel lgico los recursos para su localizacin, distribucin, o para asegurar polticas de monitorizacin o de seguridad
!!
Propsito de localizacin
!!
Propsito de diferenciacin de clientes

!!
Convenciones:
"!
Utilice / en la parte path del URI para indicar una relacin jerrquica entre recursos (RFC 3986)
"!
Utilice , y ; para indicar elementos/partes no jerrquicos/as en la parte path del URI. ; se utiliza para identificar parmetros matriciales

!!
Convenciones:
"!
Utilice - y _ de manera consistente para mejorar la legibilidad de los nombres en segmentos path largos
"!
Utilice & para separar parmetros en la porcin query del URI
"!
Evite incluir extensiones de fichero como .php, .aspx y .jsp en los URIs

!!
Convenciones:
"!
Utilice . para separar las partes documento y extensin de fichero
"!
"!
No utilice ms de un carcter . en un mismo URI para evitar resultados inesperados y/o errores en el anlisis En general, evite utilizar . en los URIs. Los clientes deben usar el tipo media de la representacin para decidir cmo procesarla. Se desaconseja que el software http infiera el tipo media a partir de la extensin de fichero

!!
Convenciones:
"!
Espacios y maysculas
!!
!!
Los espacios son caracteres vlidos. RFC 3986 obliga a que se codifiquen mediante %20. El tipo media application/x-www-form-urlencoded lo codifica mediante +. Esta inconsistencia puede ser fuente de errores Las letras maysculas tambin son fuente de errores. Los URIs son sensibles a maysculas de acuerdo con RFC 3986 excepto para las partes schema y host. Windows no sigue este criterio cuando se sirve el recurso desde el sistema de ficheros. Evite su utilizacin

!!
Convenciones:
"!
Utilice los URIs como identificadores opacos

!!
!!
Asigne las URIs como identificadores unvocos de recursos Utilice slo el URI para determinar qu recurso procesa una determinada peticin. No utilice tunneling sobre POST de cambios de estado sucesivos (sobrecarga de verbo http que usa los URIs como pasarelas y no como identificadores nicos) ni use cabeceras personalizadas para sobrecargarlas (en ambos casos se est utilizando http como prot. de transporte y no de aplicacin)

!!
Convenciones:
"!
Trate en los clientes los URIs como identificadores opacos aun a costa de reducir el rendimiento
!!
Los clientes deben poder utilizar los URIs proporcionadas por los servidores para hacer nuevas peticiones sin necesidad de entender cmo se han estructurado en el servidor (bajo acoplamiento)
"!
"!
Evite construir URIs en los clientes siempre que sea posible $! Los clientes no tienen por qu conocer cmo fabricar URIs, tan slo deben entender el significado de los valores de atributos como rel Utilice links en las representaciones para codificar detalles de implementacin directamente en los URIs

!!
Convenciones:
"!
Mantenga Cool URIs (que nunca cambian)

!!
!!
!!
La Web unciona bajo la asuncin (principio de diseo) de que los URIs son permanentes Utilice reglas de reescritura en el servidor para proteger a los clientes de cambios a nivel de implementacin Ante cambios forzosos, enve redirecciones (301 (Moved Permanently)) a los clientes con el nuevo URI (cabecera Location). Si un URI deja de ser vlido, enve 410 (Gone) o 404 (Not Found) junto con un mensaje que indique cmo encontrar el nuevo recurso o recursos relacionados

3.! Por cada Recurso, debe ofrecerse un subconjunto del Interfaz Uniforme de http
"! "! "! "! "! "!
POST GET PUT DELETE HEAD OPTIONS
(Create) (Read) (Uptate) (Delete)
Consideraciones sobre el interfaz uniforme de http

!! !! !! !! !! !!
Semntica de los mtodos http Comportamiento asncrono Interacciones visibles Gestin del estado de la aplicacin Mtodos de servidor seguros e idempotentes Uso apropiado de cabeceras http
Mtodos de servidor seguros e idempotentes

!!
!!
Un mtodo se dice seguro cuando su ejecucin no altera el estado del recurso y adems no se espera que cause efectos colaterales no intencionados (operaciones de slo lectura) Un mtodo se dice idempotente cuando su ejecucin repetida sobre el mismo recurso provoca el mismo efecto que una nica ejecucin (salvo por condiciones de carrera)
"!
!!
Un servidor http debe ofrecer implementaciones de sus mtodos que preserven estas propiedades:
Mtodo http
GET HEAD OPTIONS PUT DELETE POST
Es seguro
SI SI SI NO NO NO
Es idempotente
SI SI SI SI SI(*) NO
Esencial para recuperarse en caso de fallo
(*) Puede devolver 404 (Not Found) en lugar de 200 (OK) para cualquier recurso que no exista en el momento de la peticin
GET
!!
GET /jugador/12345 HTTP/1.1 Accept: image/png;q=0.8, text/plain;=0.2 HTTP/1.1 200 OK Content-Type: image/png \n PNG
!!
!!
Devuelve informacin (una representacin) del Recurso Identificado Admite que se solicite explcitamente el tipo de contenido Admite que se negocie el tipo de contenido
"! "!
Propiedades MIME Preferencias
!!
Operacin segura e idempotente

"!
Comportamiento esperado por clientes, sistemas de cach,etc.
POST
!!
!!
!!
Permite crear nuevos Recursos Permite que los Recursos procesen informacin (y hacer otros cambios en su estado) Operacin no segura ni idempotente
POST /juego HTTP/1.1 \n Blancas = /jugador/12345 & Negras = /jugador/54321 HTTP/1.1 201 Created Location: /partida/12345678
POST /posicion/ wpd3,wkd1,bke8 HTTP/1.1 \n Move = d3-d8 HTTP/1.1 302 Found Location: /posicion/ wpd8,wkd1,bke8
Uso del verbo POST

!! !! !! !!
Para crear un nuevo recurso, se utilizan recursos fbrica (contenedores) Para modificar (uno o) varios recursos se utilizan recursos controladores El verbo POST puede utilizarse para ejecutar consultas con gran volumen de entradas El verbo POST puede utilizarse para realizar operaciones no seguras ni idempotentes para las que no resulta apropiado ningn otro verbo http (Sec. 9.5, RFC 2616)
"! "! "! "!
Anotar recursos existentes Enviar un mensaje a un blog, a un grupo de news, a una lista de correo o a ungrupo de artculos similar Proporcionar un bloque de datos (e.g. el resultado del envo de un formulario) a un proceso de manejo de datos Aadir datos a una base de datos mediante una operacin append
Uso del verbo POST

!!
Comportamiento esperado en la infraestructura de la web

"! "! "!
Las cachs nunca almacenan la respuesta a un POST Las araas y otras herramientas similares no activan peticiones POST de manera automtica La mayora de herramientas HTTP genricas nunca reenvan peticiones POST de manera automtica
!!
Este comportamiento permite usar POST como un mtodo de propsito general, e.g. para tunneling http de mensajes XML-RPC, SOAP con http, etc. pero con ello se est haciendo un mal uso de su semntica
"!
Aun as, POST es el mtodo que menos inconvenientes provoca cuando se sobrecarga su semntica con operaciones de la aplicacin que no mapean directamente con http
Caso de Estudio: Uso del verbo POST frente a uso de extensiones HTTP
!!
!! !!
En general, para ofrecer nuevos mtodos debe disearse un recurso controlador que abstraiga dichas operaciones y pueda accederse mediante POST Sin embargo, existen iniciativas para extender HTTP Caso de Estudio:
"!
"! "!
Estudiar la iniciativa WebDAV ( http://www.webdav.org) para creacin (authoring) y versionado distribuido de documentos Pros? Cons?
Utilizacin incorrecta de la semntica de POST

POST /Messages HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=UTF-8 <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:ns="http://www.example.org/messages"> <ns:DeleteMessage> <ns:MessageId>1234</ns:MessageId> </ns:DeleteMessage> </soap:Body> </soap:Envelope>
DELETE /message/1234 HTTP/1.1 Host: www.example.org
Creacin de recursos mediante POST y recursos fbrica

# Request POST /usuario/jsoriano HTTP/1.1 Host: www.ejemplo.org Content-Type: application/xml;charset=UTF-8 Slug: Dir Domicilio <dirpostal> <calle>Campus de Montegancedo s/n</calle> <ciudad>Boadilla del Monte</ciudad> </dirpostal>
Recurso tipo coleccin usuario sirviendo de fbrica de recursos dir_domicilio. El URI del nuevo recurso lo decide la fbrica Slug (*) sugiere al servidor el uso de un nombre como parte de la uri del nuevo recurso URI del nuevo recurso URI a travs de la cual puede obtenerse la representacin del recurso usada en la respuesta
# Response HTTP/1.1 201 Created Location: http://www.ejemplo.org/usuario/jsoriano/dirpostal/dir_domicilio Content-Location: http://www.ejemplo.org/usuario/jsoriano/dirpostal/dir_domicilio Content-Type: application/xml;charset=UTF-8 <direccion> <id>urn:example:usuario:jsoriano:dirpostal:1</id> <atom:link rel="self" href="http://www.ejemplo.org/usuario/jsoriano/dirpostal/ dir_domicilio"/> <calle>Campus de Montegancedo s/n</calle> <ciudad>Boadilla del Monte</ciudad> </direccion>
(*) La cabecera Slug viene especificada por AtomPub (RFC 5023)
PUT
!!
!!
!!
Permite crear un recurso cuando el cliente puede decidir/ asignar su URI, o actualizar su informacin Un Recurso puede no soportar un Mtodo, pero sto no debe ser ignorado Operacin idempotente no segura
PUT /tablero/12345678 HTTP/1.1 \n posicion = /posicion/ wqd3,wkd2,bke8 HTTP/1.1 205 Reset Content
PUT /posicion/wqd3,wkd1,bke8 HTTP/1.1 \n posicion = /posicion/ wqd3,wkd2,bke8 HTTP/1.1 405 Method Not Allowed
Creacin de recursos mediante PUT

# Request PUT /usuario/jsoriano/dirpostal/dir_domicilio HTTP/1.1 Host: www.ejemplo.org Content-Type: application/xml;charset=UTF-8 Uso de PUT para crear un nuevo recurso dir_domicilio al que el <dirpostal> cliente puede asignar un URI <calle>Campus de Montegancedo s/n</calle> <ciudad>Boadilla del Monte</ciudad> </dirpostal> # Response HTTP/1.1 201 Created Location: http://www.ejemplo.org/usuario/jsoriano/dirpostal/dir_domicilio Content-Location: http://www.ejemplo.org/usuario/jsoriano/dirpostal/ dir_domicilio Content-Type: application/xml;charset=UTF-8 <direccion> <id>urn:example:usuario:jsoriano:dirpostal:1</id> <atom:link rel="self" href="http://www.ejemplo.org/usuario/jsoriano/ dirpostal/dir_domicilio"/> <calle>Campus de Montegancedo s/n</calle> <ciudad>Boadilla del Monte</ciudad> </direccion>
DELETE
!!
!!
Permite eliminar recursos a nivel lgico Operacin idempotente no segura
DELETE /tablero/12345678 HTTP/1.1
HTTP/1.1 204 No Content
Manejo de peticiones asncronas

!!
HTTP es un protocolo cliente-servidor, sncrono y sin estado

"!
"!
Cuando un cliente enva una peticin, espera una respuesta del servidor, tanto si se ha tratado con xito como si ha ocurrido un fallo El servidor puede no obstante devolver una respuesta antes de terminar de procesar la peticin. Para ello:
!!
!!
Al recibir una peticin POST/DELETE/UPDATE, el servidor crea un nuevo recurso tarea y, tras preprocesar la peticin, devuelve como cdigo de estado 202 (Accepted) junto con una representacin del nuevo recurso que debe incluir informacin sobre el estado de la peticin El cliente puede entonces chequear/seguir el estado de esa peticin a travs del nuevo recurso meditante GET, obteniendo:
"! "! "!
En proceso: 200 (OK) junto con informacin de estado Finalizada con xito: 303 (See Other) y una cabecera Location con el URI de un recurso que muestre el resultado de la tarea Finalizada con error: 200 (OK) y una representacin del recurso tarea con informacin sobre el fallo
Ejemplo (manejo de peticiones asncronas)

!!
Peticin POST para iniciar una nueva tarea de procesado de imgenes
(*) S. Allamaraju (2010) RESTful Web Services Cookbook, OReilly

!!
El servidor, tras preprocesar la peticin y decidir que es vlida y que puede ser atendida, crea unn nuevo recurso tarea e informa de ello al cliente

!!
El cliente puede entonces sondear (polling) al servidor hasta recibir confirmacin de la finalizacin del proceso

!!
El cliente puede entonces sondear (polling) al servidor hasta recibir confirmacin de la finalizacin del proceso
Caso de estudio: del.icio.us
EJEMPLO DE SERVICIO WEB RESTFUL
Diseos RESTful Vs. diseos POX-RPC

!!
Es comn encontrar una dificultad inicial para hacer un diseo RESTful de un servicio web
"!
"!
El principal problema recae en que REST no es algo tangible como pueda ser una especificacin o una API En su lugar, REST denota un estilo arquitectnico: un conjunto de mejores prcticas de diseo arquitectnico construidas sobre http y URI (y que a su vez sirvi de marco de trabajo para la creacin y la evolucin de esos estndares)

!!
Como consecuencia, muchos servicios web y muchas API que se denominan RESTful no lo son en realidad
"! "!
"!
Estas APIs no pueden denominarse RESTful En su lugar, deberan ser tratadas como meras APIs POX-RPC en las que se envan y reciben mensajes XML planos (sin ensobrado SOAP) meditante peticiones al estilo RPC sobre un protocolo de transporte http, utilizando un conjunto de parmetros opcionales en la cadena de consulta que influyen en los resultados obtenidos Se trata de APIs equivalentes a las ofrecidas por los servicios SOAP o XML-RPC
!!
Caso de estudio: La API del.icio.us ( http://www.delicious.com/help/api)

"! "! "!
Los objetos relevantes (bookmarks, tags, etc.) no se exponen como recursos, por lo que no podemos acceder a ellos directamente Los mtodos http no se utilizan correctamente. En su lugar todo se realiza mediante GET, incluso las operaciones que producen cambios Las representaciones de los recursos no estn interconectadas, por lo que no puede navegarse desde una lista de favoritos a un favorito en particular

!!
!! !!
En lugar de basarnos en peticiones estilo RPC a https://del.icio.us/v1/posts/get? con un conjunto de partros querystring requeridos/opcionales para acceder a los favoritos (o bien https://del.icio.us/v1/posts/all?) Podemos identificar dos recursos: favoritos y etiquetas Expondremos ambos recursos en sendos paths URI:
!!
http://misfavoritos.com/api/[usuario]/bookmarks
!!
http://misfavoritos.com/api/[usuario]/favoritos/[hash] para referirnos a un favorito en concreto. Suponemos que la aplicacin identifica unvocamente cada favorito mediante su hash http://misfavoritos.com/api/[usuario]/tags/[nombre-etiqueta] para referirnos a una etiqueta en concreto. Suponemos que la aplicacin identifica cada etiqueta mediante un nombre nico que coincide con el facilitado por el cliente
!!
http://misfavoritos.com/api/[usuario]/tags
!!
"!
Nota: No interesa delegar en la autenticacin http (http-Auth) la identificacin del usuario en cuyos favoritos estamos interesados. El URI debe ser autocontenido
!!
Idem para https://del.icio.us/v1/posts/add?, https://del.icio.us/v1/posts/delete?, etc.
Obtencin de todos los favoritos

URI Mtodo Cadena de consulta http://misfavoritos.com/api/[usuario]/favoritos/ GET tag= dt= start= end= Devuelve 200 401 404 Filtrar por etiqueta Filtrar por fecha Posicin del primer favorito solicitado Posicin del ltimo favorito solicitado OK y POX (misfavoritos/favoritos+xml) Unauthorized Not Found
Nuevos tipos MIME para identificar formatos especficos?

!!
!!
Es necesario definir tipos MIME para identificar los formatos de documento XML para las representaciones de nuestros recursos? Application/xml Vs.
Tipo MIME misfavoritos/favoritos+xml misfavoritos/favorito+xml misfavoritos/etiquetas+xml misfavoritos/etiqueta+xml Descripcin Una lista de favoritos Un favorito Una lista de etiquetas Una etiqueta
Obtencin de todos los favoritos

GET http://misfavoritos.com/api/jsoriano/favoritos/?start=1&end=2! HTTP/1.1 200 OK! <?xml version="1.0"?>! <favoritos start="1" end="2"! next="http://misfavoritos.com/api/jsoriano/favoritos? start=3&end=4">! <favorito url="http://www.example.org/one" tags="ejemplo,test"! href="http://misfavoritos.com/api/jsoriano/favoritos/ a211528fb5108cddaa4b0d3aeccdbdcf"! time="2010-10-20T10:07:34Z">! Ejemplo de favorito! </favorito>! <favorito url="http://www.example.org/two" tags="ejemplo,test"! href="http://misfavoritos.com/api/jsoriano/favoritos/ e47d06a59309774edab56813438bd3ce"! time="2010-10-21T18:30:16Z">! Otro ejemplo de favorito! </favorito>! </favoritos>!
Obtencin de todos los favoritos. Versin del.icio.us

$ curl https://user:passwd@api.del.icio.us/v1/posts/all! <posts tag="" user="user">! <post href="http://www.weather.com/" description="weather.com"! hash="6cfedbe75f413c56b6ce79e6fa102aba" tag="weather reference"! time="2005-11-29T20:30:47Z" />! ...! <post href="http://www.nytimes.com/"! description="The New York Times - Breaking News, World News & Multimedia"! extended="requires login" hash="ca1e6357399774951eed4628d69eb84b"! tag="news media" time="2005-11-29T20:30:05Z" />! </posts>!
Informacin de un favorito
URI Mtodo Devuelve http://misfavoritos.com/api/[usuario]/favoritos/[hash] GET 200 401 404 OK y POX (misfavoritos/favorito+xml) Unauthorized Not Found
Informacin de un favorito
GET http://misfavoritos/api/jsoriano/favoritos/ a211528fb5108cddaa4b0d3aeccdbdcf! <?xml version="1.0"?>! <favorito url="http://www.example.org/one! time="2010-10-20T10:07:34Z">! <descripcion>! Ejemplo de favorito! <descripcion>! <etiquetas count=2>! <etiqueta nombre=ejemplo href=http:// misfavoritos/api/jsoriano/etiquetas/ejemplo/>! <etiqueta nombre=test href=http://misfavoritos/ api/jsoriano/etiquetas/test/>! </etiquetas>! </favorito>!
Contador de posts por fecha

URI Mtodo Cuerpo de la peticin Devuelve http://misfavoritos.com/api/[usuario]/favoritos/contador GET etiqueta= 200 401 404 Filtro por etiqueta OK y entero con el nmero de favoritos (text/ plain) Unauthorized Not Found
ltima actualizacin del usuario

URI Mtodo Devuelve http://misfavoritos.com/api/[usuario]/favoritos/update GET 200 401 404 OK y fecha de la ltima actualizacin Unauthorized Not Found
Adicin de un nuevo favorito

URI Mtodo Cuerpo de la peticin Devuelve http://misfavoritos.com/api/[usuario]/favoritos/ POST POX (misfavoritos/favorito+xml) 201 401 415 Created y cabecera Location Unauthorized Unsupported Media Type
Adicin de un nuevo favorito

POST http://misfavoritos/api/jsoriano/favoritos/! <?xml version="1.0"?>! <favorito url="http://www.example.org/one time="2010-10-20T10:07:34Z">! <descripcion>! Ejemplo de favorito! <descripcion>! <etiquetas count=2>! <etiqueta nombre=ejemplo/>! <etiqueta nombre=test/>! </etiquetas>! </favorito>!
HTTP/1.1 201 Created!
Location: http://misfavoritos/api/jsoriano/favoritos/ a211528fb5108cddaa4b0d3aeccdbdcf! Content-Lenght: 0!
Modificacin de un favorito existente

URI Mtodo Cuerpo de la peticin Devuelve http://misfavoritos.com/api/[usuario]/favoritos/[hash] PUT POX (misfavoritos/favorito+xml) 201 401 404 415 Created y cabecera Location Unauthorized Not Found (*) Unsupported Media Type
(*) evita el uso de PUT para crear favoritos
Eliminacin de un favorito existente

URI Mtodo Devuelve http://misfavoritos.com/api/[usuario]/favoritos/[hash] DELETE 204 401 404 No Content Unauthorized Not Found
Eliminacin de una etiqueta existente. Versin del.icio.us
Obtencin de todas las etiquetas utilizadas por un usuario para catalogar sus favoritos
URI Mtodo Cadena de consulta Devuelve http://misfavoritos.com/api/[usuario]/etiquetas/ GET start= end= 200 401 404 Posicin de la primera etiqueta solicitada Posicin de la ltima etiqueta solicitada OK y POX (misfavoritos/etiquetas+xml) Unauthorized Not Found
Obtencin de todas las etiquetas utilizadas por un usuario para catalogar sus favoritos
GET http://misfavoritos.com/api/jsoriano/ etiquetas/?start=1&end=2! <?xml version="1.0"?>! <etiquetas start=1 end=2 next=http:// misfavoritos.com/api/jsoriano/etiquetas? start=3&end=4>! <etiqueta nombre=ejemplo count=2 href=http://misfavoritos/api/jsoriano/ etiquetas/ejemplo/>! <etiqueta nombre=test count=2 href=http://misfavoritos/api/jsoriano/ etiquetas/test/>! </etiquetas>!
Informacin de una etiqueta en particular

URI Mtodo Cadena de consulta http://misfavoritos.com/api/[usuario]/etiquetas/[nombre] GET start= end= Devuelve 200 401 404 Posicin del primer favorito para esta etiqueta solicitado Posicin del ltimo favorito para esta etiqueta solicitado OK y POX (misfavoritos/etiqueta+xml) Unauthorized Not Found
Informacin de una etiqueta en particular

GET http://misfavoritos/api/jsoriano/etiquetas/ ejemplo?start=1&end=2! <?xml version="1.0"?>! <etiqueta nombre=ejemplo>! <favoritos start=1 end=2 next=>! <favorito url="http://www.example.org/one! href="http://misfavoritos.com/api/ jsoriano/favoritos/ a211528fb5108cddaa4b0d3aeccdbdcf/>! <favorito url="http://www.example.org/two href="http://misfavoritos.com/api/jsoriano/ favoritos/e47d06a59309774edab56813438bd3ce"/>! </favoritos>! </etiqueta>!
Informacin de una etiqueta en particular. Versin del.icio.us

$ curl https://user:passwd@api.del.icio.us/v1/posts/get?tag=webdev&meta=yes! <?xml version="1.0" encoding="UTF-8"?>! <posts dt="2005-11-28" tag="webdev" user="user">! <post href="http://www.howtocreate.co.uk/tutorials/texterise.php?dom=1"! description="JavaScript DOM reference"! extended="dom reference"! hash="c0238dc0c44f07daedd9a1fd9bbdeebd"! meta="92959a96fd69146c5fe7cbde6e5720f2"! others="55" tag="dom javascript webdev" time="2005-11-28T05:26:09Z" />! </posts>! $ curl https://user:passwd@api.del.icio.us/v1/posts/get?url=http%3A%2F%2Fwww.yahoo.com %2F! <?xml version="1.0" encoding="UTF-8"?>! <posts user="user" dt="2007-12-11" tag="">! <post href="http://www.yahoo.com/" ! hash="2f9704c729e7ed3b41647b7d0ad649fe" ! description="Yahoo!" ! extended="My favorite site ever"! tag="yahoo web search" time="2007-12-11T00:00:07Z" others="433" />! </posts>!
Renombrado de una etiqueta existente

URI Mtodo Cuerpo de la peticin Devuelve http://misfavoritos.com/api/[usuario]/etiquetas/[nombre] PUT POX (misfavoritos/etiqueta+xml) (*) 204 401 404 No Content y cabecera Location (**) Unauthorized Not Found
(*) Utiliza el mtodo PUT de una etiqueta para subir una nueva representacin de la misma (**) URI de la nueva etiqueta (el nombre de la etiqueta forma parte de su URI, luego renombrarla implica cambiar su URI)
Eliminacin de una etiqueta existente

URI Mtodo Devuelve http://misfavoritos.com/api/[usuario]/etiquetas/[nombre] DELETE 204 401 404 No Content Unauthorized Not Found
Punto de entrada a la aplicacin y navegacin por sus recursos

!!
REST establece que debe utilizarse el hipertexto como motor de las transiciones entre estados de la aplicacin:
"!
"! "!
Dada una URI inicial, deberamos ser capaces de alcanzar un recurso y de utilizar las URIs presentes en su representacin para navegar a los dems recursos relacionados cuando lo deseemos El cliente de una aplicacin RESTful no debera necesitar construir o imaginar ninguna URI por si mismo Debe por tanto haber un punto de entrada (URI) para la API RESTful a partir del cual un programa que conozca los formatos de datos XML pueda encontrar toda la informacin que requiera sin necesidad de conozcer nada ms acerca del resto de la API
Obtencin de todos los usuarios

!!
En nuestro caso, el punto de entrada es la URI que da acceso a todos los recursos usuario
http://misfavoritos.com/api/ GET start= end= 200 Posicin del primer usuario solicitado Posicin del ltimo usuario solicitado OK y POX (misfavoritos/usuarios+xml)
URI Mtodo Cadena de consulta Devuelve
Obtencin de todos los usuarios

GET http://misfavoritos/api/?start=1&end=2!
<?xml version="1.0"?>! <usuarios start="1" end="2" next="http://misfavoritos.com/api/? start=3&end=4">! <usuario nombre=jsoriano"! href="http://misfavoritos.com/api/jsoriano/"! favoritos="http://misfavoritos.com/api/jsoriano/favoritos/"! etiquetas="http://misfavoritos.com/api/jsoriano/etiquetas"/>! <usuario nombre=anabelen"! href="http://misfavoritos.com/api/anabelen/"! favoritos="http://misfavoritos.com/api/anabelen/favoritos/"! etiquetas="http://misfavoritos.com/api/anabelen/etiquetas"/>! </usuarios>!
Informacin de un usuario
URI Mtodo Cadena de consulta Devuelve http://misfavoritos.com/api/[usuario]/ GET start= end= 200 401 404 Posicin del primer favorito solicitado Posicin del ltimo farovito solicitado OK y POX (misfavoritos/usuario+xml) Unauthorized Not Found
Informacin de un usuario
GET http://misfavoritos.com/api/jsoriano/?start=1&end=2! <?xml version="1.0"?>! <usuario email=jsoriano@fi.upm.es" nombre=Javier Soriano" href="http://http:// conwet.fi.upm.es/es/people/javier-soriano">! <favoritos href="http://misfavoritos.com/api/jsoriano/favoritos/" start="1" end="2"! next="http://misfavoritos.com/api/jsoriano/favoritos?start=3&end=4">! <favorito url="http://www.example.org/one href="http://misfavoritos.com/api/ jsoriano/favoritos/a211528fb5108cddaa4b0d3aeccdbdcf />! <favorito url="http://www.example.org/two" href="http://misfavoritos.com/api/ jsoriano/favoritos/e47d06a59309774edab56813438bd3ce/>! </favoritos>! <etiquetas href="http://misfavoritos.com/api/jsoriano/etiquetas/">! <etiqueta name=ejemplo" count="2" href="http://misfavoritos.com/api/jsoriano/ etiquetas/ejemplo"/>! <etiqueta name="test" count="2" href="http://misfavoritos.com/api/jsoriano/ etiquetaa/test"/>! </etiquetas>! </usuario>!
Adicin de un nuevo usuario y modificacin de la configuracin de un usuario existente

URI Mtodo Cuerpo de la peticin Devuelve http://misfavoritos.com/api/[usuario]/ PUT POX (misfavoritos/usuario+xml) 201 401 415 Created y cabecera Location Unauthorized Unsupported Media Type
(*) No se considera 404 Not Found como posible valor de retorno ya que si el usuario no existe, se crea
Adicin de un nuevo usuario

PUT http://misfavoritos/api/jsoriano! <?xml version="1.0"?>! <usuario>! <email=jsoriano@fi.upm.es/>! <nombre=Javier Soriano/> ! <href="http://http://conwet.fi.upm.es/es/people/ javier-soriano"/>! <favoritos/>! <etiquetas/>! </usuario>! HTTP/1.1 201 Created!
Location: http://misfavoritos/api/jsoriano! Content-Lenght: 0!
Eliminacin de un usuario existente

URI Mtodo Devuelve http://misfavoritos.com/api/[usuario]/ DELETE 204 401 404 No Content Unauthorized Not Found
JAX-RS y su implementacin de referencia Jersey
SERVICIOS REST EN JAVA
Servicios REST en Java

!!
!! !!
Java define un estndar de soporte para REST denominado JAX-RS (The Java API for RESTful Web Services, JSR 311, http://jcp.org/aboutJava/communityprocess/final/jsr311/index.html) JAX-RS utiliza anotaciones para definir la funcionalidad REST de las clases Java Jersey es una implementacin de referencia de JAX-RS
"!
Contiene bsicamente un servidor REST y un cliente REST (de prueba y para obtener una biblioteca de comunicacin con el servidor)
!!
A travs de web.xml se registra un servlet proporcionado por Jersey y se define el path en el que se har disponible la aplicacin web REST (clases de datos o recursos y servicios)
"! "!
La URL base de este servlet es http://your_domain:port/display-name/url-pattern/path_from_rest_class Este servlet analizar la peticin HTTP y seleccionar la clase y el mtodo apropiados para responder en base a las anotaciones hechas en clases y mtodos de la aplicacin
Anotaciones JAX-RS
Anotacin
@PATH(your_path)
Descripcin
Establece el path como URL base + your_path. La URL base se basa en el nombre de la aplicacin, el nombre del servlet y el patrn de URL del archivo web.xml Indica que el mtodo responder a una peticin HTTP POST Indica que el mtodo responder a una peticin HTTP GET Indica que el mtodo responder a una peticin HTTP PUT Indica que el mtodo responder a una peticin HTTP DELETE
@POST @GET @PUT @DELETE
@Produces Define qu tipo MIME (text/plain, application/xml, ( MediaType.TEXT_PLAIN application/json, etc.) enva un mtodo anotado con @GET [, more-types ] ) @Consumes( type [, more-types ] ) @PathParam Define qu tipo MIME consume el mtodo anotado Inyecta valores de la URL en un parmetro del mtodo anotado (por ejemplo, el ID de un recurso para obtener el objeto correcto
Ejemplo
package holaMundo; ! import javax.ws.rs.GET; ! import javax.ws.rs.Path; ! import javax.ws.rs.Produces; ! import javax.ws.rs.core.MediaType; ! @Path("/holamundo") ! public class HolaMundo { ! !@GET ! !@Produces(MediaType.TEXT_PLAIN) ! !public String sayPlainTextHello() { ! ! !throw new UnsupportedOperationException(); } ! !@GET ! !@Produces(MediaType.TEXT_XML) ! !public String sayXMLHello() { return "<?xml version=\"1.0\"?>" + <saludo> Hola Mundo" + "</saludo>"; } ! !@GET ! !@Produces(MediaType.TEXT_HTML) ! !public String sayHtmlHello() { return "<html> " + "<title>" + Hola Mundo" + "</title>" + "<body><h1>" + Hola Mundo" + "</body></h1>" + "</ html> "; } ! } !
Ejemplo. Fichero de configuracin web.xml

<?xml version="1.0" encoding="UTF-8"?> ! <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http:// java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/webapp_3_0.xsd" id="WebApp_ID" version=3.0"> ! <display-name>holaMundo</display-name> ! <servlet> ! <servlet-name>ServletAdaptor</servlet-name> ! <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</ servlet-class> ! <init-param> ! <param-name>com.sun.jersey.config.property.packages</param-name>! <param-value>HolaMundoREST</param-value> ! </init-param> ! <load-on-startup>1</load-on-startup>! </servlet> ! <servlet-mapping> ! <servlet-name>ServletAdaptor</servlet-name> ! <url-pattern>/resources/*</url-pattern> ! </servlet-mapping> ! </web-app> !
Ejemplo. Cliente
package holaMundo.cliente; ! import java.net.URI; ! import javax.ws.rs.core.MediaType; ! import javax.ws.rs.core.UriBuilder; ! import com.sun.jersey.api.client.Client; ! import com.sun.jersey.api.client.ClientResponse; ! import com.sun.jersey.api.client.WebResource; ! import com.sun.jersey.api.client.config.ClientConfig; ! import com.sun.jersey.api.client.config.DefaultClientConfig; ! public class Test { ! public static void main(String[] args) { ! ClientConfig config = new DefaultClientConfig(); ! Client client = Client.create(config); ! WebResource service = client.resource(getBaseURI()); ! System.out.println(service.path("resources").path(holamundo").accept( (ClientResponse.class).toString()); ! System.out.println(service.path("resources").path(holamundo").accept( (String.class)); ! System.out.println(service.path("resources").path(holamundo").accept( (String.class)); ! System.out.println(service.path("resources").path(holamundo").accept( (String.class)); ! } ! private static URI getBaseURI() { ! return UriBuilder.fromUri( "http://localhost:8080/").build(); ! } ! } !
MediaType.TEXT_PLAIN).get MediaType.TEXT_PLAIN).get MediaType.TEXT_XML).get MediaType.TEXT_HTML).get
Patrones de diseo para servicio web RESTFul

!!
Recurso raiz simple

"! "! "!
Crea una clase de recurso raz RESTful con mtodos GET y PUT usando la API JSR-311 Requiere de un URI y un tipo de representacin para el recurso til en la creacin de servicios cpsula para invocar servicios web basados en WSDL Crea un par de clases de recursos RESTful: una clase de recurso item y su clase de recurso contenedor usando la API JSR-311
!!
!!
Contenedor-Item
"!
!!
Permite crear y aadir recursos itemal recurso contenedor mediante un POST en el recurso contenedor (mtodo POST en la clase correspondiente) # El recurso contenedor determina el URI del recurso item recin creado Requiere de un URI y un tipo de representacin para los recursos item y contenedor
!!
Contenedor-Item controlado por el cliente

"!
Ligera variante del patrn anterior que utiliza PUT (en lugar de POST) para crear y aadir recursos item al recurso contenedor # El cliente (y no el contenedor) determina el URI del recurso item recin creado
Creacin de servicios web RESTful a partir de clases entidad

!!
Los servicios Web RESTful Java se apoyan en la API de persistencia de Java (JPA, http://download.oracle.com/javaee/6/tutorial/doc/ bnbpy.html) para comunicar con una base de datos
"!
Se apoyan en clases entidad (objetos de dominio para persistencia) que se mapean con objetos en una base de datos relacional) y en una unidad de persistencia (el conjunto de clases entidad, la fuente de datos, el proveedor de persistencia y el nombre de la unidad, como se define en el persistence.xml)

Rest

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rest

Încărcat de

Drepturi de autor:

Formate disponibile

REST: Un estilo arquitectnico para la WWW

Dr. Javier Soriano

Qu es REST? Arquitectura Vs. Estilo Arquitectnico

Qu es REST? Arquitectura Vs. Estilo Arquitectnico

Qu es REST?... En el contexto de la arquitectura de la WWW

Qu es REST?... En el contexto de la arquitectura de la WWW

Architecture of the World Wide Web, Vol. I: http://www.w3.org/TR/webarch/

Qu es REST?... En el contexto de la arquitectura de la WWW

Architecture of the World Wide Web, Vol. I: http://www.w3.org/TR/webarch/

Architecture of the World Wide Web, Vol. 1 (2005)

"! "! "!

Identificados biunvocamente mediante la sintaxis URI

Utilizada por menos del 1% de la web

Propiedad de las URIs

Identificadores de Fragmentos (elemento sintctico #) Interfaz Uniforme:

POST GET PUT DELETE HEAD OPTIONS

(Create) (Read) (Uptate) (Delete)

Principales estndares relacionados

Pginas dedicadas a HTTP del W3C

Pgina de noticias y eventos: http://www.w3.org/Protocols/ Pgina de especificaciones: http://www.w3.org/Protocols/Specs.html

Otros RFC's tiles:

Flujo de informacin en una aplicacin Complejidad Complejidad Web fortuita esencial

Diseo de un servicio RESTful paso a paso

Todo Concepto en el Dominio puede ser un Recurso

Rey Posicin Torre

Partida Caballo Pen

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Recursos compuestos (composites)

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Recursos compuestos (composites)

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Soporte para funciones de procesamiento/ computacin

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Soporte para funciones de procesamiento/ computacin

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Soporte para funciones de procesamiento/ computacin

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Uso de controladores para operar atomicamente sobre recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Uso de controladores para operar atomicamente sobre recursos

Caso de estudio: Sincronizacin de una agenda de direcciones con un servidor

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Uso de controladores para operar atomicamente sobre recursos

Diseo de un servicio RESTful paso a paso: Identificacin de recursos

Diseo de un servicio RESTful paso a paso

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Un URI es un identificador opaco de recurso

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Propsito de diferenciacin de clientes

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Utilice & para separar parmetros en la porcin query del URI

Diseo de un servicio RESTful paso a paso: Diseo de los URIs

Utilice . para separar las partes documento y extensin de fichero

Diseo de un servicio RESTful paso a paso: Diseo de los URIs