El intercambio de información entre servicios de Internet está a la orden del día. De hecho, casi es obligatorio que una aplicación aporte un conjunto de métodos (API) para la explotación de la información.
En el año 2000, Roy Fielding, definió el protocolo de intercambio y manipulación de datos, mejor conocido como REST. Este suceso revolucionó por completo el desarrollo de software. Teniendo en cuenta que estamos hablando del padre de la especificación del protocolo HTTP, podemos entender que REST es un tipo de arquitectura de desarrollo web que se apoya completamente en dicho estándar.
REST es el acrónimo de REpresentational State Transfer, que se puede traducir como “transferencia de representación de estado”. En otras palabras, estamos hablando de un servicio que no tiene estado, es decir, que en cada llamada el cliente debe recordarle al servidor quién es. No guardar el estado permite desarrollar proyectos altamente escalables, ya que no tenemos que preocuparnos de asuntos como el almacenamiento de variables de sesión, consiguiendo con ello que el servidor no agote su memoria y pueda atender muchas más peticiones.
Una característica muy importante en una API REST es que es independiente del lenguaje y del tipo de plataforma. Esto es posible ya que los formatos de lenguaje empleados como intercambio de información son: XML y JSON. Es por ello que podemos tener servidores JAVA, PHP, Pyhton o NodeJS, ya que el único requisito es que la respuesta a una petición se haga en el lenguaje de intercambio usado.
Otra de las ventajas que ofrece una API REST es la separación que existe entre el cliente y el servidor. Esto se traduce en que ambas partes pueden evolucionar de forma independiente, es decir, tanto el front-end como el back-end se pueden migrar a otros servidores sin perder con ello la funcionalidad y acoplamiento. Por ejemplo, si tanto en la petición como en la respuesta se envían los datos correctos, da igual que alguna de las dos partes haya cambiado de entorno o base de datos, por lo que podríamos estar hablando de productos muy flexibles para trabajar.
Drupal y REST
Muchas veces surgía la necesidad de tener una API REST en Drupal para manipular los datos desde aplicaciones externas como, por ejemplo, una app móvil. Hasta hace no mucho tiempo, para crear una API REST desde Drupal se necesitaban instalar y activar ciertos módulos externos. Sin embargo, en la versión 8 vienen incluidos por defecto.
En este post quiero mostrar que con muy pocos pasos podemos crear una API REST para consultar los datos de un tipo de contenido propio.
Lo que voy a hacer es generar un tipo de contenido nuevo llamado “Tarea” y, a través del cliente HTTP POSTMAN, realizar las operaciones de consultar, insertar, modificar y eliminar sus registros. Vamos a ello.
Paso 1: Creamos el tipo de contenido “Tarea”:
Accedemos a “Structure”>”Content Types” y pulsamos sobre el botón “+Add content type”. Escribimos el nombre, una descripción y guardamos.
Para este ejemplo sólo vamos a trabajar con el campo “Body” y “Title”, creados automáticamente.
Paso 2: Generamos contenido a través del gestor de Drupal para visualizar algún resultado cuando consultemos los datos:
Accedemos a “Content” y, a través del botón “+Add content”, añadimos 2 o 3 registros de tipo “Tarea”.
Paso 3: Activamos los módulos necesarios:
Accedemos a “Extend”, buscamos la sección “Web Services” y activamos todos los módulos que en ella aparecen.
Paso 4: Creamos una vista para consultar la lista de tareas:
Accedemos a “Structure”>”Views” y pulsamos sobre el botón “+Add view”.
Escribimos el nombre de la vista (Tareas), elegimos el tipo de contenido a mostrar “Tarea” en el campo tipo de la sección “VIEW SETTINGS”. A continuación, en la sección “REST EXPORT SETTINGS”, habilitamos la opción “Provide a REST export” y definimos la URL relativa para nuestra vista (en mi caso “rest/tareas”) y guardamos.
En este momento ya podríamos consultar el listado del recurso “Tarea” a través de la URL definida: http://localhost/drupal8_api/rest/tareas
Sin embargo, me gustaría también poder consultar una tarea mediante su ID. Para ello, agrego un nuevo display del tipo “REST export” dentro de la vista.
Dentro de la sección “PATH SETTINGS” definimos la ruta “/rest/tareas/%” y en la sección “ADVANCED” definimos que el filtro contextual (%) sea el ID del contenido.
Por otro lado, he modificado en la sección “FORMAT” el tipo de dato a mostrar. Por defecto se muestra toda la entidad (Entity), pero en mi caso sólo quiero ver los campos “Title”, “ID” y “Body”. Para ello selecciono la opción “Fields” en el campo “Show” y elijo los antes mencionados.
Paso 5: Configuramos el acceso a nuestra API:
Por defecto, cuando creamos la vista, no se necesita autenticación para realizar la llamada. En mi caso sólo quiero que puedan visualizar los datos los usuarios autenticados mediante el usuario y contraseña de su cuenta de Drupal. Para ello, en la sección “PATH SETTINGS” selecciono que el tipo de autenticación sea “basic auth” y el acceso se permita sólo al rol de usuarios autenticados “Role | Authenticated user”.
Por último, tenemos que permitir que el rol “Authenticated user” pueda gestionar nuestro tipo de contenido. Accedemos al menú “People” y seleccionamos la pestaña “Roles” y editamos sus permisos.
Una vez dentro, buscamos la sección “Node” y marcamos todas las opciones de nuestro tipo de contenido.
Probando nuestra API REST con POSTMAN
POSTMAN es una herramienta gratuita que permite probar servicios web fácilmente. Es muy sencilla e intuitiva. Basta con indicar la URL, el método HTTP (POST, GET, PUT, PATCH, DELETE, etc.) y los parámetros de la petición. Una vez lanzada la petición, captura la respuesta en XML, JSON o texto de una forma clara.
Para probar nuestra API y emplear los métodos más habituales HTTP (GET, POST, PATCH y DELETE) voy a aclarar las 3 variables de cabecera que vamos a encontrar en los ejemplos:
- X-CSRF-Token: cabecera necesaria para evitar ataques CSRF. En Drupal podemos obtener el token en la ruta: “rest/session/token“
- Authorization: el tipo de autenticación. En nuestra API hemos configurado la autenticación básica, por tanto debemos codificar nuestro “user:pass” y enviarlo en la cabecera. Postman nos permite generar automáticamente este parámetro en la pestaña “Authorization” de su interfaz.
- Content-Type: tipo de contenido que enviamos. En nuestro caso “application/hal+json“
Consultar – Método GET
URL: http://localhost/drupal8_api/rest/tareas
Headers: Content- Type y Authorization
Respuesta: Listado de las tareas en formato JSON
Consultar una tarea por ID – Método GET
URL: http://localhost/drupal8_api/rest/tareas/ID
Headers: Content- Type y Authorization
Respuesta: Tarea con ID=2 en formato JSON
Crear una tarea – Método POST
URL: http://localhost/drupal8_api/entity/node
Headers: X-CSRF-Token, Content- Type y Authorization
Respuesta: Entidad completa de la tarea creada en formato JSON
Actualizar una tarea – Método PATCH
URL: http://localhost/drupal8_api/node/ID
Headers: X-CSRF-Token, Content- Type y Authorization
Respuesta: Entidad completa de la tarea modificada en formato JSON
Eliminar una tarea – Método POST
URL: http://localhost/drupal8_api/node/ID
Headers: X-CSRF-Token, Content- Type y Authorization
Respuesta: 204 No Content
Conclusión…
Como hemos visto, la creación de una API REST en Drupal 8 es muy sencilla de realizar gracias a los módulos incluidos por defecto.
No he querido profundizar en cada concepto porque no era el objetivo de este post. Espero que os sea de utilidad.
En futuros posts intentaré hacer uso de nuestra API REST para gestionar las tareas desde una aplicación real externa.
Recursos:
http://asiermarques.com/2013/conceptos-sobre-apis-rest/
http://www.desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html
https://drupalize.me/blog/201401/introduction-restful-web-services-drupal-8
https://drupalize.me/blog/201402/your-first-restful-view-drupal-8
