Web Service - REST

Los web services permiten a los programas escritos en diferentes lenguajes y que se ejecutan sobre diferentes plataformas comunicarse entre ellos siguiendo estándares.

Hay casos en los que lo que se quiere resolver es el acceso a recursos provistos por otras aplicaciones haciendo especial énfasis en la optimización de tráfico HTTP (es importante cuando los clientes son dispositivos móviles por ejemplo). En ese caso entra REST como estilo de diseño de servicios web, que garantiza la interoperablidad bajo un paradigma de simplicidad y “ahorro de recursos”.

Básicamente el objetivo es exponer datos de una aplicación o lo que vamos a llamar “recursos” o entidades, en la web, con una salida con un formato estándar (XML, Json), para que sea interpretable por un programa que ejecute sobre cualquier plataforma o framework, e incluso sobre cualquier cliente HTTP.

Qué es REST?

Representational State Transfer o REST es un estilo de arquitectura de software, para ambientes distribuidos. No se trata de un protocolo.

REST es un modelo orientado a recursos. Básicamente significa que cada URL es la representación de un objeto - o recurso. Cada recurso se representa con una URI. Se puede hacer un GET de ese recurso usando el método GET de HTTP, modificar el mismo con el método HTTP PUT, crear una nueva representación con POST y borrar con el método DELETE (es decir que existe una interfaz uniforme para acceder a los recursos). Por su parte, cada recurso tiene n representaciones posibles, puede ser XML, Json.

Rest marca una serie de reglas o restricciones. Los seguidores de REST afirman que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales clave, justamente en base a estos fundamentos es que se crearon las principios o constraints que debe cumplir una arquitectura REST.

Web Services vs REST, Ventajas y desventajas.

Una de las dudas típicas a la hora de integrar dos subsistemas heterogéneos es si usar web services o REST. Evidentemente, si los dos subsistemas estuvieran desarrollados con el mismo lenguaje de programación, la integración obvia sería aprovechar lo que nos facilitase ese lenguaje, como puede ser RMI o .NET Remoting por citar sólo dos ejemplos.

Resulta que tenemos que integrar dos módulos que están desarrollados en dos entornos diferentes; o a lo mejor el requisito es que se comuniquen por internet, aunque compartan lenguaje de programación. En estos casos, hay que estudiar si es mejor realizar esta integración mediante web services o con llamadas REST. 

Ventajas y desventajas de hacerlo de una manera o de otra.
Los web services tienen como principal ventaja que cualquier entorno de desarrollo (Eclipse, Netbeans, Visual Studio, etc), dispone de herramientas para generar un cliente a partir de un WSDL o exponer los métodos de una clase como servicios web. No obstante, es muy recomendable hacer una prueba de concepto antes de decidirse porque si el cliente y el servidor de servicios web no están basados en las mismas librerías, se puede tener problemas de compatibilidad.

Como ejemplo, si tenemos un cliente .NET en una PDA y un servicio web en J2EE (que use las librerías Axis, por ejemplo), es posible que si tenemos un dato de tipo timestamp, el valor sea diferente en la parte Java y en la parte .NET

Pero quizá lo más fácil de detectar sea la compatibilidad a la hora de encapsular ficheros dentro de un web service: ya que hay varios mecanismos (SwA - SOAP with Attachments, DIME o MTOM), es posible que si las librerías son distintas en cliente y servidor, no exista una manera compatible de transferir un fichero, teniendo que recurrir a soluciones de contingencia como montar un servicio intermedio (desarrollado con el mismo lenguaje de programación y librerías que el servidor de servicios web) que reciba el fichero como parte de un form-multipart y que luego lo encapsule de forma compatible para el destinatario final (el servicio web).

Por otro lado, los web services proporcionan otras ventajas como el tipado fuerte (en el WSDL está definido de qué tipo son las variables, incluso en el caso de objetos complejos) o los estándares WS-*: WS-I BasicProfile, WS-Security, WS-Addressing, WS-RM o WS-Policy. De usarla es necesario asegurarse de la compatibilidad entre librerías si son distintas en cliente y servidor.

En el caso de utilizar REST, perdemos lo del tipado fuerte y los mecanismos estándares WS-* mencionados anteriormente, pero ganamos universalidad: muchos dispositivos programables son capaces de hacer peticiones HTTP. Eso significa que podemos integrar una aplicación desarrollada en J2ME con nuestro servidor sin necesidad de que soporte la JSR para web services.

Hasta hace poco, no había manera de generar clientes de manera automática para hacer invocaciones REST. Afortunadamente, existe la librería Jersey del proyecto GlassFish, que permite desarrollar tanto servicios de servidor basados en REST (simplemente con etiquetas en los lugares oportunos) como clientes que los consuman de manera automática. Esto es debido a que los servicios generados con esta librería despliegan un descriptor WADL muy similar al WSDL de los web services tradicionales, por lo que luego se puede partir de ahí para generar los clientes correspondientes.

Para subir o bajar ficheros si optamos por esta modalidad, basta con utilizar comunicaciones HTTP estándar como POST (con un form-multipart, por ejemplo) o GET (una simple petición a la URL de un fichero); ambos mecanismos son sencillos de implementar y hay muchos ejemplos en internet en casi cualquier lenguaje de programación.

Para implementar REST, debemos seguir los 4 principios básicos:

• utiliza los métodos HTTP de manera explícita: Una de las características claves de los servicios web REST es el uso explícito de los métodos HTTP, siguiendo el protocolo definido por RFC 2616.
Este principio de diseño básico establece una asociación uno-a-uno entre las operaciones de crear, leer, actualizar y borrar y los métodos HTTP. De acuerdo a esta asociación:

    o   se usa POST para crear un recurso en el servidor

    o   se usa GET para obtener un recurso

    o   se usa PUT para cambiar el estado de un recurso o actualizarlo

    o   se usa DELETE para eliminar un recurso

• No mantiene estado: El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envíen peticiones completas e independientes; es decir, se deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan re direccionar y gestionar la carga sin mantener el estado localmente entre las peticiones.

• Expone URIs con forma de directorios: Las URI de los servicios web REST deben ser intuitivas, hasta el punto de que sea fácil adivinarlas.

• transfiere XML, JavaScript Object Notation (JSON), o ambos: La representación de un recurso en general refleja el estado actual del mismo y sus atributos al momento en que el cliente de la aplicación realiza la petición. La última restricción al momento de diseñar un servicio web REST tiene que ver con el formato de los datos que la aplicación y el servicio intercambian en las peticiones/respuestas.