10 junio, 2008

Cuando REST mató a SOAP

Leyendo un artículo en exuys.com que intenta explicar REST con unas palabras distintas a las oficiales, llego a la conclusión de que la explicación no me convence. Tampoco me gusta la de la wikipedia, pero sí la de Tomayko.com explicándole el concepto a su mujer. Mi versión es la que sigue.

REST es un estilo de programación para establecer una conexión con servidores e intercambiar información. Con REST se definen recursos conceptuales que tienen una representación y que son accesibles por medio de una cadena de texto llamada URI. Visto así puede parecer complejo, pero si cambiamos URI por URLs como http://digitta.com, cambiamos los recursos por páginas web y cambiamos su representación por HTML o SWF, todo empieza a tener un aire más familiar.

Cuando apareció SOAP, un protocolo complejo por el cuál un programa solicita información a un servidor, se tuvo en cuenta todo el conocimiento que hasta el momento se había utilizado, por lo que se pensó en componentes especiales tanto en el cliente como en el servidor. Pero eso añadía una capa más de complejidad que REST ha demostrado totalmente innecesaria:

Con REST, las peticiones se realizan a servidores web. Los verbos GET, POST, PUT o DELETE que ya pertenecían al protocolo HTTP desde sus inicios, se adaptan como un guante a las cuatro acciones estándar CRUD (Create, Read, Update, Delete). El que usamos habitualmente cuando introducimos una dirección en el navegador y pulsamos intro es GET, que se adapta perfectamente a la lectura/visualización de un recurso.

La enorme ventaja de utilizar REST es que pueden probarse en el navegador introduciendo a mano (o a través de formularios) las peticiones al servidor e inspeccionar el resultado de la misma forma con la que visitaríamos una página web. Todas las piezas estaban ya ahí y sólo era cuestión de usarlas de forma adecuada, con la ventaja añadida de que todas las características de HTTP como balanceo de carga, cachés, proxys, compresión de datos transmitidos, etc. están automáticamente disponibles.

Para comprobar la tremenda sencillez del concepto REST y la razón por la que se está imponiendo, vale una simple llamada a la API de tinyurl.com (un servicio web gratuito para acortar direcciones largas por otra equivalente mucho más corta):

http://tinyurl.com/api-create.php?url=http://digitta.com

A primera vista es una simple dirección web, pero cuyo resultado...

http://tinyurl.com/4can6t
...no está pensado para ser visualizado por un humano sino consumido por un programa. El servicio no distingue ambos usos y poder ver el resultado en el navegador permite comprender rápidamente el funcionamiento del servicio o probarlo para detectar errores sin necesidad de pelearse con componentes y con el código para prepararlos.

0 comentarios:

Publicar un comentario



Últimos links en indiza.com