How to model file system operations with REST?

Question

There are obvious counterparts for some of file systems' basic operations (eg. ls and rm), but how would you implement not straightforwardly RESTful actions such as cp or mv?

As answers to the question How to implement copy paste of a resource in REST? suggest, the preferred way of implementing cp would include GETting the resource, DELETing it and PUTting it back again with a new name.

But what if I would need to do it efficiently? For instance, if the resource's size would be huge? How would I eliminate the superfluous transmission of resource's payload to client and back to the originating server?

Here is an illustration. I have a resource:

/videos/my_videos/2-gigabyte-video.avi

and I want copy it into a new resource:

/videos/johns_videos/copied-2-gigabyte-video.avi

How would I implement the copy, move or other file system actions the RESTful way? Or is there even a proper way? Am I doing it all wrong?

Answer 1

To my opinion, the video is a resource. So this resource has a path. what if you do an UPDATE that change the resource path ?

Then, in your code, if it changes the path, you just have to move the file.

Answer 2

One way to do this is to formulate your PUT/POST requests such that you can either give the actual data or give the URL of the resource, possibly with the option to make a hard or symbolic link. If the given URL is hosted on your own system, then you can simply point internally to the same file, possibly keeping a bit for "copy-on-write" or something along those lines in order to make it efficient.

Answer 3

[...the preferred way of implementing cp would include GETting the resource, DELETing it and PUTting it back again with a new name.]

One problem with the above approach is lack of atomicity and consistency. Since each of the operations (GET, DELETE and PUT) happen over HTTP (which is stateless inherently) the server cannot enforce atomicity. For any reason, the client may abort after any step before the last step and that would leave the server with an inconsistent state in terms of its data.

A possible approach:

• If the resources are documents (which I guess, they are in your case) I'd explore the option of using WebDAV.
• If WebDAV is not an option --
  • create a controller object on the server to manage copy and move operations, client can POST to something like /videos/my_videos/[video_id]/copy
  • In your response you can specify the URI to the copied resource, in the lines of:

HTTP/1.1 201 Created

Content-type:video/x-msvideo

Location:/videos/johns_videos/8765

Note: I prefer sending an ID back and working with resource IDs rather than something like

Location: /videos/johns_videos/copied-2-gigabyte-video.avi

Move operation is pretty similar except that the server may accept a destination resource. Example:

http://example.com//videos/johns_videos/8765/move?destination=[destination]

You can extend the above approach such that the server sends a Last-Modified tag to the client and client sends that along with its request. The server will perform the copy/move operations only when that value is still consistent. This will address concurrency issues with the resource being changed while your copy/move operations are still in progress.

Answer 4

You could expose a new service that takes (POST) a simple xml doc that outlines what you want to do.

<move>
   <target>/videos/my_videos/2-gigabyte-video.avi</target>
   <destination>/videos/johns_videos/copied-2-gigabyte-video.avi<destination>
<move>

Then this service could return a URI where the client can go and check the status of the operation. Then the client could interact with that new resource to say cancel the move if still pending, or check on it's success.

Answer 5

REST is not limited to HTTP! The best way would be to use webdav for your problem.