Introducción servicios RESTful

Los servicios web son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web. Ya que un servicio web esta identificado por un URI.

Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.

Como se puede ver en el esquema superior, varias tecnologías y plataformas son intercomunicadas mediante distintos servicios web. De forma que independientemente del lenguaje de programación en el que esté implementado cada subsistema, gracias a los servicios web, dichos subsistemas pueden intercambiar datos para poder realizar sus operaciones.

Servicios RESTful

Uno de los servicios web más importantes y más usados son los servicios RESTful. Vamos a describir sus principales características:

A) Se basan en HTTP para intercambiar información, realizando peticiones a recursos, y no necesitan encapsulado extra para ello. Es más ligero, menos engorroso, pero al mismo tiempo tiene más limitaciones que el otro gran tipo de servicios web: SOAP.  En vez de hacer peticiones encapsuladas en un sobre SOAP, en los servicios REST las peticiones se hacen mediante el protocolo HTTP, con GET, POST... sin necesidad de encapsular nada. Lo que simplifica el proceso.

 Una petición HTTP consta de: 

- Una URL y un método de acceso (GET, POST, PUT,…). 

- Cabeceras. Meta-información de la petición. 

- Cuerpo del mensaje (opcional). 

Vamos a describir las funciones que deberían de realizar cada uno de los método de acceso disponibles en un servicio RESTful:

1. GET: Se utiliza para solicitar una representación del recurso especificado. Nunca puede modificar ningún recurso.

2. POST:
- Se utiliza para enviar datos para que sean procesados (p.e. formularios) en el recurso indicado. Por ejemplo para enviar credenciales de autenticación.
- También se utiliza para crear (http://localhost/servicio/crearUsuario) un nuevo recurso cuando es el sistema el que le asigna un identificador. El cual se utilizará para poder acceder al recurso mediante peticiones: http://localhost/servicio/usuario/1. Si volvemos a hacer una petición POST  para crear un usuario, con los mismos datos, el sistema asignará otro identificador y por lo tanto otra URL de acceso:  http://localhost/servicio/usuario/2

3. PUT:
- Se utiliza para remplazar en el servidor una representación de un recurso ya existente. Podríamos asimilarlo como un “UPDATE”. Por ejemplo petición a http://localhost/servicio/actualizarNombre/1.
- También se utiliza para crear un nuevo recurso en una URL especificada. Esto quiere decir que si sabemos el identificador que tendrá un recurso al crearse, y por lo tanto lo pasamos junto con los datos de creación, utilizaremos PUT.
Esto lleva a decir que el método PUT es idempotente. Ya que podemos hacer múltiples peticiones PUT a la misma URL y siempre estaremos accediendo al mismo recurso. Sin embargo las peticiones POST no son idempotentes, ya que si hacemos una petición POST  para crear un recurso y es el sistema el que asigna su identificador, obtendremos una URL de acceso diferente a la que obtendremos en una siguiente petición de la misma índole.

4. DELETE: Se utiliza para eliminar el recurso especificado.

Conceptualmente hablando, lo correcto sería que cada petición responda realizando las funcionalidades descritas. Sin embargo, en muchos sistemas reales, las funciones que deberían de realizar las peticiones de tipo PUT y DELETE son realizadas por peticiones POST. La petición POST se utiliza tanto para crear, borrar o actualizar un recurso. Y por lo tanto las peticiones PUT y DELETE no son utilizadas.

B) Lo importante son los recursos. Podemos pensar que un recurso es como una entidad que representa un concepto que puede ser accedido públicamente. Un ejemplo de recurso sería simplemente “Clientes” y otro podría ser “Cliente código. 38″.

-Cada recurso, de acuerdo a los principios de laprogramación orientada a objetos, posee un identificador único y global que lo distingue de cualquier otro recurso, aunque ambos tuvieran exactamente los mismos datos. 

-Lo único accesible de un recurso desde el exterior, es su representación. Y por ello se entiende como al formato de datos concreto usado para la transferencia de una copia de la representación pública del recurso entre el cliente y el servidor. 

C) Sin estado. Cada petición de un cliente debe contener toda la información necesaria. No puede beneficiarse del contexto almacenado en el servidor . Lo que quiere decir, por ejemplo, que si una petición requiere autentificación, habrá que enviar las credenciales del usuario con cada petición. No se puede hacer login y crear una sesión para el usuario.

La ausencia de estado en el servidor elimina la necesidad de sincronizar los datos de la sesión con una aplicación externa. Con lo que se mejora el rendimiento del servicio web.

D) Exponer URIs con estructura de directorios. Lo que significa que es recomendable crear servicios web con URIs amigables:

- Ocultar la tecnología usada en el servidor que aparecería como extensión de archivos (.jsp, .php, .asp), de manera de poder portar la solución a otra tecnología sin cambiar las URI.

- Mantener todo en minúsculas.

- Sustituir los espacios con guiones o guiones bajos (uno u otro).

- URLs amigables  es más aconsejado que el uso de strings de consulta. Evitar www.ejemplo.com/app.php?id=2 y sustituirlo por www.ejemplo.com/2. Para ello es importante el uso de las reglas de reescritura. 

E) La implementación del recurso decide que información es visible o no desde el exterior, y que representaciones de dicho recurso se soportan. Existen 3 posibles representaciones más comunes para un recurso son:

- XHTML

- XML

- JSON

Pero no sólo podemos representar el recurso como datos estructurados (aunque si es lo más común). Podríamos pedir por ejemplo, una representación en formato imagen. Esta variedad de representación de los recursos del servicio permite que pueda ser usado por clientes. Diseñados en diferentes lenguajes de programación y que pueden ejecutarse en arquitecturas completamente distintas. El uso de los tipos MIME y del encabezado HTTP-Accept es un mecanismo conocido como negociación de contenido, el cual le permite a los clientes elegir qué formato de datos puedan leer, y permite un desacoplamiento de datos entre el servicio y las aplicaciones que lo consumen.

Un ejemplo de servicio web seria la petición GET a un recurso “usuario” de twitter :
http://api.twitter.com/1/users/show.json?screen_name=twitter

y la respuesta, con la representación JSON del recurso, es la siguiente:

{"id":783214,"id_str":"783214","name":"Twitter","screen_name":"twitter","location":"San Francisco, CA","url":"http:\/\/blog.twitter.com\/","description":"Your official source for news, updates and tips from Twitter, Inc.","protected":false,"followers_count":19286285,"friends_count":121,"listed_count":77531,"created_at":"Tue Feb 20 14:35:54 +0000 2007","favourites_count":22,"utc_offset":-28800,"time_zone":"Pacific Time (US & Canada)","geo_enabled":true,"verified":true,"statuses_count":1588,"lang":"en","status":{"created_at":"Wed May 22 19:36:13 +0000 2013","id":337290822204653569,"id_str":"337290822204653569","text":"Make your Twitter account more secure with login verification, in 4 easy steps: ...}


Conclusión

Para terminar podemos concluir diciendo que un servicio RESTFul es un servicio accesible desde la Web y que ofrece un API (funciones o métodos remotos) para que un cliente realice peticiones a los diferentes recursos. Independientemente de la implementación interna del servicio para manejar los recursos, este proporcionará una representación de la petición al cliente. Esto permite una total independencia de la implementación y arquitectura de los sistemas/clientes que utilicen el servicio RESTful.