2011-06-28 12 views
8

Tengo un servicio web RESTful que representa procesos y actividades. Cada actividad está dentro de un solo proceso. Me gustaría representar una operación de "movimiento" de actividad entre el proceso en el que se encuentra actualmente y otro proceso.Mover recursos en arquitectura RESTful

He visto foros y encontré personas que sugieren utilizar la operación MOVE que no es muy estándar y otras sugieren usar PUT pero entonces no estoy seguro de cómo diferenciar entre PUT que actualiza y PUT que se mueve se ve semánticamente mal.

¿Alguna idea?

Respuesta

3

Si se utiliza PUT, se puede notar la diferencia en función de si el proceso de la entidad existente coincide con la nueva.

PUT /process1/activity2\n\n 
process: 2 
some_data: and_stuff 

A lo que la respuesta lógica (si tiene éxito) es

303 See Other\n 
Location /process2/activity2 
+0

Es posible que también desee utilizar "204 Sin contenido" en lugar del 303: http://grzegorzborkowski.blogspot.nl/2009/04/relocating-resources-with-restful-web.html – mb21

8

Una forma podría ser para representar el movimiento en sí como, por ejemplo, un recurso de "transferencia" (transferencia como sustantivo), y POST una nueva:

POST /transfer 

con una entidad que contiene:

activity: /activities/4 
toProcess: /processes/13 

de esta manera, los clientes están creando nuevos "transferencias" que, en el servidor, se encargan de validación y transferencia de la actividad.

Esto le da la capacidad de agregar información acerca de la transferencia, también. Si desea mantener un historial de auditoría, puede agregar una propiedad transferredBy al recurso, o una fecha transferredOn.

+0

Hola, este es idea interesante. No pensé en utilizar la transferencia en sí como recurso, pero supongo que de eso se trata REST. ¿Crees que es bueno que al crear (publicar) un nuevo recurso de transferencia, se cambie otro recurso? –

+1

Sí, eso está perfectamente bien. POST no tiene que ser [idempotent] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2), por lo que puede tener efectos secundarios. –

+0

+1. Esta es la forma en que también he pensado. Creo que esto es más limpio que un PUT en el elemento contenido siempre que el movimiento deba afectar tanto al contenedor (su lista de elementos contenidos) como al elemento contenido (su campo de enlace principal). Sin embargo, me pregunto si REST se trata de ser limpio en ese sentido. ¿Está bien suponer que alguien más PUT en el padre cada vez que ponemos en el niño? ¿O deberíamos preocuparnos por ser RESTfully correctos incluso cuando miramos el conjunto completo de solicitudes reales hechas por cualquier cliente? –

Cuestiones relacionadas