Según los gurús del estilo REST uno de sus puntos fuertes respecto a SOAP es su sencillez. Y no dudo que no sea más sencillo, pero lo que tengo claro es que requiere un relativamente gran esfuerzo implementar servicios de este tipo. ¿Por qué digo esto?. Por la inercia de llevar varios años diseñando servicios SOAP.

Si seguimos el estilo REST tendremos que volver un poco a los orígenes, a la esencia misma de HTTP. Un protocolo que se inventó para trabajar con recursos y las típicas operaciones CRUD de toda aplicación de gestión. Y eso está muy bien, el problema está en que llevamos muchos años trabajando, y pensando, de otra manera.

Digamos que a lo largo de estos años hemos utilizado el protocolo HTTP para implementar nuestras aplicaciones apartándonos del estándar. Hace ya unos años, cuando empecé con la programación con java en el servidor, al menos respetaba la diferencia entre una operación HTTP GET de un POST. Así las funcionalidades de consulta, que no cambiaban el estado de la aplicación las implementaba con un GET, mientras que aquellas que tenían como efecto un cambio en la base de datos, se hacían mediante un POST.

Volviendo a aprender a diseñar URL

Este mínimo seguimiento del estándar HTTP, se olvido por completo con el uso de los frameworks (caso de Struts por ejemplo). Directamente todo iba por POST.

Caso parecido pasó con las URL. Olvidamos muy pronto que significan «localizador universal de recurso» y las desnaturalizamos hasta construir unas URL artificiales tipo midominino.com/miAplicacion/consultarSaldo.do?cuenta=123 o incluso peor. Cosa que nos llevó años después a descubrir que no eran «amigables«.

Tal es nuestra «deformación profesional» que si ahora nos ponemos a pensar en cómo serían unas URL bien formadas, que definan recursos (para lo que fueron diseñadas) nos cuesta un gran esfuerzo. Especialmente recomendable es este artículo de http://redrata.com/restful-uri-design/

Según este blog, las URL deben ser:

  • cortas
  • autodescriptivas del recurso
  • predecibles: viendo una debería ser muy fácil adivinar la de otro recurso
  • nombres, no verbos
  • la URL debe continuar funcionando mientras el recurso exista.
  • y muchas más

Control de errores

Otro tanto paso con el control de errores y códigos de retorno que se devuelven al usuario. Son varias decenas los códigos de retorno que define HTTP (no hay más que ver la página de W3C) , sin embargo, nos empeñamos a usar uno únicamente, el 500.

Por poner un par de ejemplos, si estamos haciendo la consulta de una cuenta corriente, y ésta no existe, no hay que devolver un error 500 con un texto del estilo «cuenta corriente no existe». En este caso, tal como se podría esperar, hay que devolver un códo 404, que significa ni más ni menos eso, el recurso no existe.

Si en un recurso de sólo lectura, intentamos ejecutar la operación DELETE, es necesario devolver un error 501, que significa precisamente que el método no está implementado.

En resumen, sobre los códigos devueltos no debemos reinventar la rueda, debemos mirar la lista de códigos HTTP y devolver uno de ellos. Deberían ser suficientes para todos los casos.

Conclusión

Lo que percibo de todo esto es que el formato REST de servicios es más sencillo pero nos cuesta bastante pensar y diseñar servicios de este tipo porque estamos viciados por muchos años de darle la espalda al protocolo HTTP.

Tendremos que hacer un esfuerzo de desaprender antes de aprender de nuevo.

Comparte esta entrada:
Share

Licencia de Creative Commons
Pensando en SOA by Andrés Hevia is licensed under a Creative Commons Reconocimiento 3.0 Unported License