office-195960_640

Los servicios RESTFul están de moda, eso está claro. Tanto es así, que prácticamente no se utiliza otro tipo de servicios en los desarrollos de apps móviles o en la construcción de de APIs.

Mi percepción personal es que el uso de servicios SOAP en las empresas se está reduciendo a aquellos casos en los que se quiere reutilizar servicios ya existentes o en el caso de que se tengan unos requerimientos muy especiales. Entre estos estaría por ejemplo, cuando dos empresas quieren tener un servicio en el ámbito B2B con unas necesidades de seguridad muy altas (cifrado, firmas, no repudio, etc. etc.).

Aunque ganamos muchas otras características y ventajas propias de los servicios REST, al no utilizar servicios SOAP perdemos algunas cosas. Y una de estas, creo que la más básica, es la pérdida de un instrumento para la definición del contrato del servicio, me refiero claro al WSDL.

En SOAP, todos tenemos claro que si queremos expresar el contrato del servicio de manera no ambigua, aunque un poco farragosa, tenemos este formato que está totalmente extendido y utilizado. No se entiende SOAP sin WSDL por decirlo brevemente. Por desgracia, no existe al día de hoy nada equivalente para REST.

A mi juicio un contrato en un servicio debe de servir al menos para dos cosas y sería deseable una tercera. Me explico:

  1. En primer lugar un contrato debe de servir para poner de acuerdo a dos partes y saber cada una que es lo que espera de la otra. Dicho de otro modo, un contrato de servicio debe de reflejar cual es el interfaz del servicio (que parámetros entran y cuales salen), los códigos devueltos (HttpCodes) y una indicación de lo que hace ese servicio. A partir de aquí, las dos partes (que pueden ser dos equipos de desarrollo diferentes) pueden empezar a trabajar por separado.
  2. Validación en tiempo de ejecución. Un contrato debería servir para que en el momento de recibir un mensaje con la petición del cliente, se pueda comprobar si la petición cumple el contrato. Es decir, validar el mensaje de entrada y devolver un error en el caso de que esté mal.
    Como nota curiosa sobre esta funcionalidad, podemos ver que en algunas instalaciones está desactivada la validación en tiempo de ejecución por razones de rendimiento. Puestos todos los aspectos en la balanza se considera que si se ha probado convenientemente en los entornos no productivos, se entiende entonces que los mensajes cumplirán con el contrato sin tener que validarlo en runtime.
  3. La tercera sería facilitar el desarrollo de un servicio y del cliente. Es decir, tal como lo hace SOAP con el WSDL, sería deseable que la herramienta de desarrollo pudiera leer este contrato (tendría que ser procesable por un programa) y generase el código necesario para poder hacer una invocación (un proxy) y en el lado del servidor lo necesario también para validar el mensaje automáticamente.

Y la falta de un verdadero estándar de facto no es por carencia de alternativas. Tenemos muchas y variadas, desde del clásico documento Word donde se cuenta en lenguaje natural el contrato, hasta otros formatos como el WADL o el mismísimo WSDL que se quiere reciclar y contemplar también este tipo de servicios.

WSDL 2.0

Para la definición de servicios REST con WSDL se necesita al menos la versión 2.0 de este lenguaje de descripción. Esto hace que las posibilidades de utilización en la práctica se minimicen. Es necesario actualizar el Middleware de muchas empresas para poder contar con él. Y eso a veces es poco menos que imposible, sobre todo si tenemos esto como única justificación de la inversión necesaria.

Además, haciendo honor a su tradición, el WSDL 2.0 sigue siendo demasiado farragoso y no digerible por el común de los mortales. Quizás es un contrasentido que se implementen los servicios con REST por ser una manera más sencilla y quizás más intuitiva que SOAP para luego tener que lidiar con un contrato a la antigua usanza. Puede acabar siendo más complicado definir el contrato que hacer el servicio.

WADL

El Web Application Description Language es un XML que se utiliza para describir un servicio HTTP como puede ser un servicio REST.

Desde el punto de vista de la empresa, estaríamos incluso peor que en el caso anterior. Es difícil poner un nuevo Middleware que de soporte a esto y es más difícil aún difundir su uso dentro de la misma.

Captura de pantalla 2015-02-22 a las 8.05.13

WADL es en definitiva un formato XML basado en esquema XSD, un estándar muy potente pero muy “verboso”, farragoso y que cuando se empieza a complicar es difícil de leer por el ojo humano. Sin embargo, fácil de leer por el “ojo” del ordenador, es decir, es fácilmente procesable y no es ambiguo.

JSON Schema

Es un contrato expresado en un documento JSON, el formato “natural” de los servicios REST. Como todos los esquemas es bastante verboso, pero creo es más fácil de leer a simple vista.

En esta página se puede ver un ejemplo y realizar algunas pruebas. A modo de ejemplo, y para hacernos una idea de este tipo de esquema, podemos ver que para validar un sencillo mensaje JSON:

Captura de pantalla 2015-02-22 a las 8.23.08

Se necesita otro JSON 4 veces más largo:

Captura de pantalla 2015-02-22 a las 8.23.14

 

El documento de toda la vida

Captura de pantalla 2015-02-22 a las 7.56.14

Pues como es obvio, esto es ni más ni menos que hacer un documento, en perfecto lenguaje natural en el que se dice que hace el servicio y se trata de indicar cuál es su interfaz.

Como todos los documentos en lenguaje natural suele ser ambiguo, no completo y sujeto alguna que otra interpretación. Sin embargo, es rápido de hacer y fácil de leer.

Tampoco se puede utilizar para que la herramienta de desarrollo pueda generar código por nosotros, pero sin embargo, tiene una cualidad básica: está tremendamente extendido.

¿Qué tendría que tener al menos este tipo de contrato?. Algunas cosas básicas serían:

  • Descripción de lo que hace el servicio
  • URI del recurso
  • Método HTTP (get, post….)
  • Códigos HTTP devueltos. Y no sólo los errores, todos los códigos que pueda devolver (por ejemplo devolver un 201 cuando se crea un servicio correctamente)
  • Ejemplo de mensaje de entrada y de salida

Conclusión

Como conclusión diría que la implementación mediante servicios REST tiene un “gap” importante (como se dice ahora ;-). La falta de un contrato formal puede dificultar el desarrollo de servicios ya que no tenemos una herramienta para expresar estos contratos en lenguaje “informático”.

Sin embargo, a pesar de esto, los servicios REST se usan y se construyen cada vez más. ¿Será que el contrato no es lo más importante para un servicio? Obviamente lo más importante es el servicio en sí, pero yo estaría más tranquilo si tuviera un contrato con las ventajas del WSDL en SOAP.

 

 

 

Anuncios