image

En el desarrollo de aplicaciones, tenemos todo un clásico: el esquema maestrodetalle. Para el que no lo conozca, esto viene a decir que una entidad (detalle) depende de otra (el maestro) por lo que sin la existencia de éste no existiría. Un ejemplo común sería el de un pedido y las líneas de pedido. Un pedido tiene n líneas de pedido y una línea de pedido sólo puede pertenecer a una orden de pedido.
Este es un esquema típico como digo, ¿pero como lo pasamos a servicios REST?

El primer paso es definir los recursos, las URIS y las operaciones sobre estos. Pongámonos en el caso de que queremos desarrollar una tienda en la que se hacen pedidos. Cada pedido estará formado por varias líneas de pedido… Con servicios SAP tal vez tendríamos un servicio llamado Gestión de Pedidos varias operaciones :

.–Crear pedido
. –Añadir línea de pedido
. –Etc.

Sin embargo, si diseñamos esta misma funcionalidad con servicios REST la cosa cambia bastante.

Como sabéis, cada recurso se caracteriza por que tiene un identificador único, la URI, y sobre él sólo podemos ejercer las acciones o verbos que nos da el protocolo HTTP: GET, POST, DELETE, PUT…

Teniendo esto en cuenta tendríamos entonces lo siguiente :

/tienda/pedido

POST crea un nuevo pedido y le asigna un identificador
GET devuelve todos los pedidos existentes
Se puede indicar un filtro para la búsqueda

/tienda/pedido/:idPedido

GET: obtiene la información de un pedido con identificador idPedido
POST: Actualiza el pedido
DELETE: borra le pedido

/tienda/pedido/:idPedido/linea

GET obtiene las líneas del pedido con identificador idPedido
POST crea una nueva línea depedido en el pedido con identiicador idPedido y le asigna un identificador de línea de pedido

/tienda/pedido/:idPedido/linea/:idLinea

GET obtiene esa línea de pedido
POST actualiza esa línea de pedido
DELETE borra esa línea de pedido

Yo suelo decir que hay que pensar en los recursos como si fuera ‘fotografías’ que guardamos en nuestro disco duro. ¿cual sería la ruta del disco para acceder a estas fotos –recursos?
Ahora imaginad que sobre estas fotos del disco duro, en el explorador de archivos, le dais con el botón derecho del ratón y os salen las cuatro operaciones típicas: abrir, crear nuevo, eliminar y editar…. Pues eso mismo (salvando las distancias claro) podríamos decir que es como se modelan los recursos REST de nuestra aplicación.

En conclusión:
Si venimos de los servicios SOAP debemos pensar de otra manera e incluso simplificar nuestra forma de pensar.

NOTA: este POST esta escrito íntegramente con un smartphone… Sólo decir que el esfuerzo se multiplica por tres 😉