Move resource in RESTful architecture

I have a RESTful web service which represent processes and activities. Each activity is inside one and only one process. I would like to represent a "move" operation of activity between the process it is currently in and another process.

I've look at forums and found people suggest to use MOVE operation which is not very standard and other开发者_开发知识库 suggest to use PUT but then I'm not sure how to tell the difference between PUT that update and PUT that moves which looks semantically wrong.

Any ideas?

---

One way might be to represent the move itself as, say, a "transfer" resource (transfer as a noun), and POST a new one:

POST /transfer

With an entity containing:

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

This way, clients are creating new "transfers" which, on the server, handle validating and transferring the activity.

This gives you the ability to add information about the transfer, too. If you wanted to keep a history for auditing, you could add a transferredBy property to the resource, or a transferredOn date.

---

If using PUTs, you can tell the difference by whether the process of the existing entity matches the new one.

PUT /process1/activity2

process: 2
some_data: and_stuff

To which the logical response (if successful) is

303 See Other
Location: /process2/activity2

---

Given the available answers I'm not really satisfied with the proposals.

POST is an all purpose method that should be used if none of the other operations fit the bill. The semantics of a payload received are defined by the service/API only and may therefore a solution for one API but not for most ones. It further lacks the property of idempotency which in case of a network issue will leave the client in an uncertainty whether the request received the server and only the response got lost mid way or if the request failed to reach the server at all. A consecutive request might therefore lead to unexpected results or further actions required.

PUT has the semantics of replace the current representation obtainable from the resource (may be empty) with the representation provided in the payload. Servers are free to modify the received representation to a more fitting one or to append or remove further data. PUT may even have side effects on other resources as well, i.e. if a versioning mechanism for a document update is provided. While providing the above-mentioned idempotency property, PUT actually does not fit the semantics of the requested action. This might have serious implications on the interoperability as standard HTTP servers wont be able to server you correctly.

One might use a combination of POST to create the new representation on the new endpoint first and afterwards remove the old one via DELETE. However, this are two separate operations where the first one might fail and if not handled correctly lead to an immediate deletion of the original resource in worst case. There is no real transactional behavior in these set of operations unfortunately.

Instead of using the above mentioned operations I'd suggest to use PATCH. PATCH is a serious of changes calculated by the client necessary to transform a current representation to a desiered one. A server supporting PATCH will have to apply these instructions atomically. Either all of them are applied or none of them at all. PATCH can have side effects and is thus the most suitable fit to perform a move in HTTP currently. To properly use this method, however, a certain media-types should be used. One might orientate on JSON Patch (more reader-friendly) i.e., though this only defines the semantics of operations to modify state of JSON based representations and does not deal with multiple resources AFAIK.