El objetivo de este artículo es describir cómo puede proporcionarse accesibilidad REST a los servicios web de TrustedX. Es decir, cómo puede implementarse una interfaz de acceso REST a dichos servicios (TrustedX REST API).

Ventajas de una API REST

La principal ventaja que tiene acceder a los servicios web de TrustedX a través de una API REST es la simplicidad. En general, los servicios web a los que se puede acceder a través de una interfaz REST son muy fáciles de consumir, lo cual simplifica la programación y el mantenimiento de los clientes y redunda en la consiguiente reducción de sus costes.

Además, el acceso REST a los servicios web de TrustedX aumenta el desacoplamiento entre TrustedX y los clientes que consumen estos servicios, salvaguardando a los clientes de la posible evolución de los mismos.

Distintos planteamientos para implementar una API REST sobre TrustedX

En Ejemplos REST se ha adoptado un planteamiento RPC (Remote Procedure Call) de la API REST de TrustedX. Según este enfoque (REST-RPC) cada una de las funciones de TrustedX se considera como un "recurso" capaz de proporcionar una representación de la variación de estado que debe experimentar toda aplicación que acceda a él (GET, POST) y le proporcione como entrada, una representación de determinada parte de su estado (i.e. de una parte que tenga una semántica determinada).

Por ejemplo, si por cualquier medio, una aplicación ha obtenido el certificado de una entidad, puede considerarse que la información correspondiente a dicho certificado, forma parte del estado que actualmente tiene la aplicación en cuestión. Puede considerarse, también, que es posible "aumentar" (i.e. modificar) el estado de esa aplicación con la información relativa a la validez que tenga el certificado en ese momento.

A tal efecto, la aplicación realiza un POST sobre el recurso que conceptualmente corresponda a la capacidad que tiene TrustedX de validar certificados (e.g. certificates/validation) y le pasa como entrada, una representación textual (i.e. en XML) del certificado cuya validez quiere conocer. A continuación, el recurso de TrustedX (i.e. la función de validación de certificados) obtiene la información sobre la validez del certificado y devuelve a la aplicación consumidora una representación textual (i.e. en XML) de dicha información la cual, al ser recibida por la aplicación, pasa a formar parte de su estado.

El planteamiento REST-RPC resulta adecuado cuando una aplicación quiere ejecutar funciones de seguridad sobre los datos que forman parte de su estado y no quiere que estos datos ni los que resulten de la ejecución de las funciones de seguridad sean "publicados" como recursos accesibles fuera del estado. Este es, por ejemplo, el escenario en el que se sitúa la validación de un certificado que una aplicación haya obtenido. La aplicación quiere conocer si es válido el certificado que ella tiene (i.e. el certificado que forma parte de su estado) y no si es válido un "recurso-certificado" que supuestamente es igual al que forma parte de su estado, pero que se encuentra fuera de él.

En otros casos, en cambio, puede ser más recomendable adoptar un enfoque ROA (Resource Oriented Architecture) a la hora de implementar una API REST de TrustedX. En general, dicha aproximación resultará ser la mejor en aquellas situaciones en las que, a partir de datos que inicialmente formen parte del estado de una aplicación, puedan llegar a generarse recursos que sean manipulables fuera de él. Un ejemplo claro de este escenario es el acceso REST al servicio de custodia de firmas de TrustedX. En dicho escenario, a partir de datos que forman parte del estado de una aplicación (e.g. unos datos que se quieren firmar), TrustedX genera un recurso (e.g. la firma de dichos datos) de cuyo mantemiento pasa a encargase a continuación (e.g. actualizando periódicamente la firma con sellos de tiempo y otras evidencias de no-repudio) y del que puede proporcionar una representación a cualquier aplicación que la solicite.

Implementación de la API REST mediante la configuración del componente SmartGateway

En sentido estricto, no existe una API REST a la que podamos denominar "la" API REST de TrustedX sino que, mediante la configuración adecuada del componente SmartGateway, se puede implementar sobre TrustedX cualquier API REST que "tenga sentido" y que se adapte a las características concretas de un escenario en particular.

En términos generales, la manera de implementar una API REST sobre los servicios de TrustedX es mediante la definición de un conjunto de pipelines XML. De este modo, cada pipeline encapsula una funcionalidad concreta de TrustedX y es ejecutado cada vez que se invoca alguno de las métodos (HTTP-POST, HTTP-GET) de la interfaz del "recurso" mediante el que, a su vez, el componente SmartGateway encapsula a dicho pipeline. En realidad, para que la ejecución del pipeline pueda producirse deberán cumplirse, además, el conjunto de condiciones que el componente SmartGateway haya establecido para él (e.g. uno de los parámetros de la URI del mensaje HTTP de petición tiene un determinado valor, el message-body del mensaje HTTP de petición contiene un determinado elemento XML).

Siguiendo una filosofía coherente con la de los servicios (firma, verificación, validación, etc), cada pipeline XML que se define en TrustedX está incluido dentro de una regla del componente SmartGateway que, a su vez, puede ser englobada dentro de una o varias políticas, también del SmartGateway, y que tiene un conjunto de condiciones asociadas que condicionen su aplicabilidad y, por tanto, la ejecución del pipeline.

Además, cada política del SmartGateway tiene asociada una lista de URI (de identidades de recursos) de forma que éstos quedan también asociados a cada una de las reglas (i.e. pipelines) que están englobadas dentro de la política (e.g. un caso típico consiste en asociar una sóla URI a cada política).

Como consecuencia de lo anterior, para TrustedX, en el contexto REST, una acción que sea solicitada sobre el recurso virtual que identifica una determinada una URI, es una acción que deberá ejecutarse según lo que establezca la política de SmartGateway que esté asociada dicha URI. Esto significa que la acción solicitada provocará la ejecución del pipeline que esté dentro de la primera regla de la política que resulte aplicable, es decir, de la primera para la que TrustedX verifique que se cumplen sus condiciones.

Utilizamos cookies para mejorar nuestro sitio web y su experiencia al usarlo. Las cookies utilizadas para el funcionamiento esencial de este sitio ya se han establecido. Para obtener más información sobre las cookies que utilizamos y cómo eliminarlas, ver nuestra Política de Privacidad.Acepto las cookies de este sitio