Drupal Services
Agustin Casiva
[email protected]
www.42mate.com
Intro
Hoy en día las arquitecturas web son complejas, el viejo y sencillo modelo LAMP está prácticamente
obsoleto. Hoy en día el ecosistema es muy diverso, debemos integrar aplicaciones (feeds, twits,
facebook, otros sitios), tenemos diversos clientes (celulares, tablets, televisores, browsers, otros
sitios). Desde el backend la cosa no es muy diferente, tenemos diversos backends de datos (MySQL,
Redis, Memcache, ElasticSearch, Solr, Otros sitios).
Para poder intercomunicar todos estos productos que cumplen un rol dentro de la aplicación
necesitamos algún canal basado en un protocolo de comunicación para lograr el intercambio de
información.
Algunos protocolos son estandares, como el protocolo de comunicación a MySQL el cual es bien
conocido y requiere un driver para permitir la interacción el cual implementa el estándar establecido.
Otros son específicos e implementados por la desarrolladores de la aplicación.
La forma más sencilla que tienen los developers hoy en día para crear estos canales de comunicación
específicos para sus aplicaciones son los Web Services. Basándose en un protocolo bien conocido de
comunicación, por ejemplo HTTP, montan sus servicios aceptando datos de entrada y devolviendo
información del sistema en algún formato fácilmente procesable por otro sistema (XML, Json, CSV,
etc). Existen diferentes tipos de servicios web, SOAP, REST, XMLRPC entre otros, pero sin dudas los
más prácticos y más controversiales hoy en día son los servicios REST.
La filosofía de los servicios REST es reutilizar toda la infraestructura de la World Wide Web y el
protocolo HTTP para interconectar aplicaciones. En criollo, asi como pedimos una página web
diciendo
https://www.google.com.ar/?gfe_rd=cr&ei=CkGIVq6AKsqB8Qemj7XYCQ&gws_rd=ssl#q=rest
y este devuelve una página web con la información legible para humanos, la idea es que podamos
hacer la misma petición pero obtener la información en un formato legible por un sistema asi el
mismo puede procesarla y hacer lo que necesite con la misma.
De la misma forma, enviando peticiones http poder impactar cambios en el estado sistema remoto.
Estas URLs que expone el sistema remoto se conocen como endpoints, y el conjunto de endpoints se
conoce como la API del sistema remoto.
La controversia viene de la mano que REST establece cómo deben realizarse estas peticiones y la
forma en que deben implementarse los endpoints para que tengan un sentido común para la API que
provee el sistema remoto. Muchas veces como desarrolladores no seguimos adecuadamente estas
reglas y se generan discusiones de lo mal o bien que hicimos nuestra API. Un mal diseño de una API
puede traer problemas serios si nuestro sistema crecerá en endpoints, si crecerá el número de
developers que desarrollaran la API y si crece el número de clientes que tendremos. Lo mejor será
seguir las reglas de REST, las cuales son sencillas, desde el día 0 y estar seguro que el equipo las
conoce a la hora de extender y mantener la API.
Entonces, antes de comenzar con APIs REST deberían tener bien claro
● El protocolo HTTP, verbos, urls, headers, codigos de respuesta
● Cómo usar HTTP para hacer REST
● Autenticación y Autorización
● Seguridad
Un buen libro para conocer estas cosas es "Build APIs You Won’t Hate" escrito por Phil Sturgeon.
Y Drupal ?
Drupal provee un conjunto de módulos muy prácticos para implementar APIs REST en nuestros Web
Sites basados en Drupal los cuales aseguran que sigamos estos lineamientos y que sea muy fácil
hacerlo. Asi y todo, puedo dar fe como algunos developers lo hacen mal de todos modos, pero si te
preocupa hacerlo bien, Drupal te la hace muy fácil.
El principal módulo es Services, este módulo provee casi todo lo necesario para implementar servicios
web bien implementados relativamente fácil. Services es agnóstico al protocolo a usar, que conozca
posee soporte para SOAP, XMLRPC y REST, solo debemos instalar los servers que son módulos
adicionales que corren sobre services y realizar la integración de los mismos. Yo solo he trabajado con
REST asi que hablaré de este Server.
Por otro lado, un gran problema de los servicios REST es la autenticación y la autorización. Existen
varias formas de validar quién es el que realiza las peticiones (Autenticación) y si puede o no realizar
la acción y/o consultar los datos (Autorización). Existen protocolos para hacer este proceso y también
hay muchas discusiones sobre cual es la mejor forma de hacerla. El mecanismo más conocido por
estos días es Oauth2 el cual es un protocolo para autenticar y autorizar servicios web basándose en
tokens. No soy un experto en Oauth2 pero trataré de explicar aquí lo necesario para que lo integren
en su Drupal. Existe un módulo que provee soporte para Oauth2 a los endpoints expuestos por
Services llamado intuitivamente Oauth2.
De aquí en más trataré de explicarles cómo configurar los módulos, les mostraré como realizar
autorizaciones y autenticaciones, como implementar nuevos endpoints y como usar herramientas
para probar sus endpoints.
Instalación de Módulos
Partiremos desde una instalación limpia de Drupal con un profile por defecto.
Descargaremos los módulos
Services
Libraries
Chaos Tools
Entity API
Entity Reference
X Autoload
OAuth2 Server
Vamos a habilitar
● Services
● REST Server
● OAUTH2 Server
● Libraries
Libraries necesita la libreria https://github.com/bshaffer/oauth2serverphp, hay que bajar la ultima
versión, descomprimir y ponerla en el directorio libaries.
Con esos módulos habilitados ya estamos para comenzar a configurar los servicios.
Configurando el Servicio
Para comenzar a configurar el servicio debemos ir a Structure > Services, ahi veremos una pantalla
como esta, iremos a Add para añadir una API nueva.
Para crear necesitaremos completar este formulario
Primero nos pide el machine name, un identificador para la API.
Nos pide elegir un server, solo habilitamos REST.
Path al endpoint, de aquí se desprenden todos los recursos que definamos para la API, es básicamente
el prefix para las urls que definimos.
Luego si queremos podemos tildar debug el cual nos dejará información en el dblog.
Por último nos pide autenticación, podemos usar basada en session (usando la cookie de session de
PHP) o basada en Oauth2. Ambas funcionan y tienen sus pro y cons, veremos ambos casos, por ahora
para hacerlo simple dejaremos sin autenticación.
Una vez creado lo tendemos en la lista de services que definimos, observe que podemos crear varios
tipos de services, ideal para manejar diferentes versiones de nuestra API o para soportar diferentes
tipos de Web Services (SOAP, XMLRPC, etc).
En Edit Resources podremos habilitar o deshabilitar los recursos disponibles en este service.
Antes de avanzar veamos que hay en la solapa Server
.
En esta podemos definir, para el server REST, qué response formats soportaremos (como serán las
respuestas) y de qué forma podemos definir los payloads de nuestras request. Como ven hay varias
opciones disponibles (normalmente cuando hacemos algo custom no se tienen en cuenta todas estas
alternativas), por ahora solo dejaremos disponibles las opciones basadas en json.
Resources
Los resources son las funcionalidades que implementamos para exponer a través del servicio. Cuando
vayamos al código implementaremos resources, los resources estarán disponibles para todos los
services, en cada service podemos habilitar o deshabilitar los ressources que expondremos a traves
del service.
Para comenzar a entender este concepto veamos los recursos que services nos trae por defecto.
Por defecto, service provee resources para interactuar con los pilares de drupal, nodos, taxonomías,
usuarios, files y algunas funciones del sistema. Probaremos habilitar algunos resources de nodos para
probar.
Si abrimos las opciones en node veremos que tenemos
CRUD Operations : La base de REST, permite Crear, Leer, Updatear o Borrar un recurso individual
Action : Sirve para hacer alguna acción en los recursos, ejemplo actualizar nodos en solr.
Targeted actions : Sirve para hacer una acción en un recurso particular, ejemplo publicar/despublicar nodo
Relationships : Sirve para implementar acciones siendo sugar syntactic a un recurso en particular, ejemplo
comentarios de un nodo.
El REST server automáticamente mapea estos conceptos con los verbos http, entonces, teniendo
C,R,U,D,I = Create, Read, Update, Delete (CRUD) and Index requests
A = Action
T = Targeted action
X = Relationship request
Para entender cómo pedir cada uno de estas operaciones podemos usar las siguientes tabla.
COUNT |0|1|2|3|4|N|
GET |I|R|X|X|X|X|
POST |C|A|T|T|T|T|
PUT | |U| | | | |
DELETE| |D| | | | |
Count se refiere a la cantidad de elementos en el path, por ejemplo, para el resource news en nuestro caso el path es
demo/api/v1/news, hasta ahí es el recurso y el count es 0. Si ahora decimos demo/api/v1/news/223, el count sera
de 1 y 233 es el nid de la news. Si fuese una targeted action podría ser demo/api/v1/news/233/unpublish, el count
es 2 y unpublished será usado para saber que targeted action usar, caso similar sería si fuese una relationship
request.
En resumen, que para poder pegar a un recurso index debemos usar GET. Para actualizar un recurso
debemos usar PUT, para borrar un recurso debemos usar DELETE. Para realizar una acción sobre node
debemos usar POST. Para realizar una targeted action debemos usar POST. Lo único que nos falta
saber es la url del endpoint a utilizar.
Por ahora, en resources, habilitemos retrieve e index. Ambos podrán ser utilizados
Crear cuenta
Comentarios de: Drupal Services (0)
No hay comentarios