Download Tema03-restful - Web de Lenin Lemus

Restful
JAX-RS
Java API for RESTful Web Services es una API del lenguaje de
programación Java que proporciona soporte en la creación de servicios
web de acuerdo con el ​estilo arquitectónico Representational State
Transfer (REST).
JAX-RS usa anotaciones, introducidas en Java SE 5, para simplificar el
desarrollo y despliegue de los clientes y puntos finales de los servicios
web.
A partir de la versión 1.1 en adelante, JAX-RS es una parte oficial de Java
EE 6.
Una característica notable de ser parte oficial de Java EE es que no se
requiere configuración para comenzar a usar JAX-RS.
Para los entornos que no son Java EE 6 se requiere configurar
el descriptor de despliegue web.xml.
Especificación
JAX-RS proporciona algunas anotaciones para ayudar a mapear una clase
recurso (un POJO) como un recurso web. Entre estas anotaciones se
incluyen:
@Path especifica la ruta de acceso relativa para una clase recurso o
método.
@GET, @PUT, @POST, @DELETE y @HEAD especifican el tipo de
petición HTTP de un recurso.
@Produces especifica los tipos de medios MIME de respuesta.
@Consumes especifica los tipos de medios de petición aceptados.
Anotaciones adicionales
@PathParam enlaza el parámetro a un segmento de ruta.
@QueryParam enlaza el parámetro al valor de un parámetro de consulta
HTTP.
@MatrixParam enlaza el parámetro al valor de un parámetro de matriz de
HTTP.
@HeaderParam enlaza el parámetro a un valor de cabecera HTTP.
@CookieParam enlaza el parámetro a un valor de cookie.
@FormParam enlaza el parámetro a un valor de formulario.
@DefaultValue especifica un valor por defecto para los enlaces anteriores
cuando la clave no es encontrada.
@Context devuelve todo el contexto del objeto.
(Por ejemplo: @Context HttpServletRequest request)
JAX-RS 2.0
En enero de 2011, se formó un grupo de expertos para trabajar en JAXRS 2.0.
Los objetivos principales fueron una API de cliente común y el apoyo a
Hipermedia siguiendo el principio HATEOAS de REST.
En mayo de 2013 se publicó la versión final
Implementaciones
Apache CXF, un framework de servicios web de código abierto.
Jersey, la implementación de referencia de Sun (ahora Oracle).
RESTeasy, implementación de JBoss.
Restlet, creado por Jerome Louvel, un pionero en frameworks de REST.
Apache Wink, proyecto de Apache Software Foundation Incubator, el
módulo del servidor implementa JAX-RS.
JBoss, la librería org.jboss.resteasy da soporte de JAX-RS sobre la
plataforma JBoss.
JERSEY
De acuerdo con el Tutorial de Java EE 6, Volumen 1: Jersey es la
implementación de referencia de calidad de producción de Sun para JSR
311: JAX-RS: The Java API for RESTful Web Services.
Jersey implementa soporte para las anotaciones definidas en la JSR-311,
lo que facilita a los desarrolladores crear servicios web RESTful con Java
y la JVM de Java.
Jersey también añade características adicionales no especificadas por la
JSR.3
Transferencia de Estado
Representacional (REST)
Es un estilo de arquitectura software para sistemas hipermedia
distribuidos como la World Wide Web.
El término se originó en el año 2000, en una tesis doctoral sobre la web
escrita por Roy Fielding, uno de los principales autores de la
especificación del protocolo HTTP y ha pasado a ser ampliamente
utilizado por la comunidad de desarrollo.
Conceptos detrás de REST
originalmente REST se refería a un conjunto de principios de arquitectura,
en la actualidad se usa en el sentido más amplio para describir cualquier
interfaz entre sistemas que utilice directamente HTTP para obtener datos o
indicar la ejecución de operaciones sobre los datos, en cualquier formato
(XML, JSON, etc) sin las abstracciones adicionales de los protocolos basados
en patrones de intercambio de mensajes, como por ejemplo SOAP.
Es posible diseñar sistemas de servicios web de acuerdo con el estilo
arquitectural REST de Fielding y también es posible diseñar
interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento
remoto (RPC), pero sin usar SOAP.
Estos dos usos diferentes del término REST causan cierta confusión en las
discusiones técnicas, aunque RPC no es un ejemplo de REST.
Los sistemas que siguen los principios REST se llaman con
frecuencia RESTful:
Escalabilidad
REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños
fundamentales clave:
Un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la información necesaria
para comprender la petición.
Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones
entre mensajes.
Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros mecanismos
para mantener el estado de la sesión
◦ algunas de estas prácticas, como la reescritura de URLs, no son permitidas por REST
Un conjunto de operaciones bien definidas que se aplican a todos los recursos de información: HTTP en
sí define un conjunto pequeño de operaciones, las más importantes son POST, GET, PUT y DELETE.
Con frecuencia estas operaciones se equiparan a las operaciones CRUD en bases de datos que se
requieren para la persistencia de datos, aunque POST no encaja exactamente en este esquema.
Una sintaxis universal para identificar los recursos.
En un sistema REST, cada recurso es direccionable únicamente a través de su URI.
El uso de hipermedios, tanto para la información de la aplicación como para las transiciones de estado
de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML.
Como resultado: es posible navegar de un recurso REST a muchos otros, simplemente siguiendo
enlaces sin requerir el uso de registros u otra infraestructura adicional.
Recursos
Un concepto importante en REST es la existencia de recursos (elementos de información),
que pueden ser accedidos utilizando un identificador global (un Identificador Uniforme de
Recurso).
Para manipular estos recursos, los componentes de la red (clientes y servidores) se
comunican a través de una interfaz estándar (HTTP) e intercambian representaciones de
estos recursos (los ficheros que se descargan y se envían) - es cuestión de debate, no
obstante, si la distinción entre recursos y sus representaciones es
demasiado platónica para su uso práctico en la red, aunque es popular en la
comunidad RDF.
La petición puede ser transmitida por cualquier número de conectores (por ejemplo
clientes, servidores, cachés, túneles, etc.) pero cada uno lo hace sin "ver más allá" de su
propia petición (lo que se conoce como stateless (sin estado), otra restricción de REST, que
es un principio común con muchas otras partes de la arquitectura de redes y de la
información).
◦ Una aplicación puede interactuar con un recurso conociendo el identificador del recurso y la acción
requerida, no necesitando conocer si existen cachés, proxys, cortafuegos, túneles o cualquier otra
cosa entre ella y el servidor que guarda la información. La aplicación, sin embargo, debe
comprender el formato de la información devuelta (la representación), que es por lo general un
documento HTML o XML, aunque también puede ser una imagen o cualquier otro contenido.
REST frente a RPC
Una aplicación web REST requiere un enfoque de diseño diferente a una
aplicación basada en RPC
REST frente a RPC
En RPC, se pone el énfasis en la
diversidad de operaciones del
protocolo, o verbos; por ejemplo
una aplicación RPC podría definir
operaciones como:
En REST, el énfasis se pone en los recursos, o sustantivos;
especialmente en los nombres que se le asigna a cada
tipo de recurso.
Por ejemplo, una aplicación REST podría definir algunos
tipos de recursos asignándoles estos nombres:
•
•
•
•
•
•
•
•
•
•
•
•
•Usuario {}
•Localización {}
getUser()
addUser()
removeUser()
updateUser()
getLocation()
addLocation()
removeLocation()
updateLocation()
listUsers()
listLocations()
findLocation()
findUser()
Cada recurso tendría su propio identificador, como
http://www.example.org/locations/us/ny/new_york_city
.
Los clientes trabajarían con estos recursos a través de las
operaciones estándar de HTTP, como GET para descargar
una copia del recurso.
•
•
Cada objeto tiene su propia URL y puede ser fácilmente
cacheado, copiado y guardado como marcador.
POST se utiliza por lo general para acciones con efectos
laterales, como enviar una orden de compra o añadir ciertos
datos a una colección.
Implementaciones
La blogosfera en su mayor parte, basado en REST, dado que implica descargar ficheros XML (en formato RSS o Atom) que contienen listas de enlaces a otros recursos.
Amazon.com ofrece su interfaz para desarrolladores tanto en formato REST como en formato SOAP (siendo la versión REST la que recibe mayor tráfico).
eBay ofreció hasta 2008 una interfaz REST para desarrolladores.
El Proyecto "Seniors Canada On-line" del Gobierno de Canadá ofrece una interfaz REST descrito aquí.
Bloglines ofrece una API basada en REST para desarrolladores.
Yahoo! ofrece una API en REST para desarrolladores.
El mecanismo de enrutamiento de Ruby on Rails soporta aplicaciones REST utilizando el patrón de diseño MVC.
Microsoft tiene su implementación en ADO.NET Data Services Framework (anteriormente conocido como “Astoria”) .
El mismo mecanismo en Catalyst también soporta aplicaciones REST mediante MVC.
El publicador de objetos de Zope.
Facebook ofrece una API basada en REST.
Twitter ofrece una API basada en REST.
MEGA ofrece una API basada en REST.
MercadoLibre ofrece una API basada en REST para desarrolladores.
HATEOAS
Abreviación de Hypermedia As The Engine Of Application State
Es una restricción de la arquitectura de aplicación REST que la distingue
de otras arquitecturas de aplicación.
El principio básico es que un cliente interactúa con una aplicación a
través de hipermedios proporcionados por servidores de aplicaciones
◦ Un cliente REST no necesita conocer a priori como interactuar la aplicación
hipermedia
◦ En contraste, en algunas arquitecturas orientadas a servicios (SOA), los
clientes y los servidores interactúan a través de una interfaz fija definida a
través e documentos IDL
La restricción HATEOAS desaclopa a un cliente y a un servidor de forma
que permite que la funcionalidad del servidor evolucione
independientemente
Detalles
A REST client enters a REST application through a simple fixed URL.
◦ All future actions the client may take are discovered within resource
representations returned from the server.
◦ The media types used for these representations, and the link relations they
may contain, are standardized.
◦ The client transitions through application states by selecting from the links
within a representation or by manipulating the representation in other ways
afforded by its media type.
◦ In this way, RESTful interaction is driven by hypermedia, rather than out-ofband information.
For example, [2] here is a GET request to fetch an Account resource,
requesting details in an XML representation:
GET /account/12345 HTTP/1.1 Host: somebank.org Accept: application/xml
HTTP/1.1 200 OK Content-Type: application/xml Content-Length: ... <?xml
version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">100.00</balance>
<link rel="deposit" href="https://somebank.org/account/12345/deposit" />
<link rel="withdraw" href="https://somebank.org/account/12345/withdraw"
/> <link rel="transfer"
href="https://somebank.org/account/12345/transfer" /> <link rel="close"
href="https://somebank.org/account/12345/close" /> </account>
Note the response contains 4 possible follow-up links - to make a deposit, a
withdrawal, a transfer or to close the account.
Some time later the account information is retrieved again, but now the
account is overdrawn:
HTTP/1.1 200 OK Content-Type: application/xml ContentLength: ... <?xml version="1.0"?>
<account>
<account_number>12345</account_number>
<balance currency="usd">-25.00</balance>
<link rel="deposit"
href="https://somebank.org/account/12345/deposit" />
</account>
Now only one link is available: to deposit more money. In its current
state, the other links are not available.
◦ Hence the term Engine of Application State.
◦ What actions are possible vary as the state of the resource varies.
A client does not need to understand every media type and
communication mechanism offered by the server.
The ability to understand new media types can be acquired at run-time
through "code-on-demand" provided to the client by the serve
Orígenes
The HATEOAS constraint is an essential part of the "uniform interface"
feature of REST, as defined in Roy Fielding's doctoral
dissertation. Fielding has further described the concept on his blog.
The purpose of some of the strictness of this and other REST
constraints, Fielding explains, is "software design on the scale of
decades: every detail is intended to promote software longevity and
independent evolution. Many of the constraints are directly opposed to
short-term efficiency. Unfortunately, people are fairly good at shortterm design, and usually awful at long-term design".
Implementaciones
Spring HATEOAS parte del Spring Framework
Yii 2 Framework REST API soporta HATEOAS,
Jersey API soporta HATEOAS
Tastypie soporta HATEOAS
Apigility, API builder based on Zend Framework 2, soporta HATEOAS
Hateoas PHP library, soporta HATEOAS REST Web Services
implementations.