3

How would you implement copy-paste support in a RESTful way?

Let's say I have book store resource. And books in every store

http://mydomain.com/rest/book-stores/1
http://mydomain.com/rest/book-stores/1/books/12

I need the client to be able to invoke copy paste of a book to another store.

Implementing the following:

PUT http://mydomain.com/rest/books/1/copy-paste

seems very RPC like. Do you have any suggestion how can this operation be modeled in a RESTful way?

LiorH
  • 18,524
  • 17
  • 70
  • 98
  • 2
    What does that mean? Copy from where? Paste to where? Are you talking about all server side? – dustyburwell May 13 '09 at 18:03
  • good comment, I will update the question – LiorH May 13 '09 at 18:26
  • This [question](http://stackoverflow.com/questions/5555620/how-to-move-a-rest-resource) shows a quite nice example of moving a resource. – ssedano Feb 10 '12 at 08:52
  • This [question](http://stackoverflow.com/questions/5555620/how-to-move-a-rest-resource) shows a quite nice example of how to move. – ssedano Feb 10 '12 at 08:53
  • This [question](http://stackoverflow.com/questions/5555620/how-to-move-a-rest-resource) shows a quite nice example of a move. – ssedano Feb 10 '12 at 08:53

3 Answers3

9

Copy = GET http://mydomain.com/book/1

Paste = PUT http://mydomain.com/book/2 or POST http://mydomain.com/book

Paul Morgan
  • 31,226
  • 3
  • 24
  • 27
1

This is only a problem if your resources are organized to mimic a hierarchical system. Like a file system.

I prefer non-hierarchical resources. The "path" to a file would just be a property of the file. To copy-paste, there are two options.

  1. If you really just want another "path" reference, add another entry for the "path" property. The same exact file is "in" both "folders".

  2. If you need to new version of the file, effectively forking changes thereafter, create a new resource (different URI) with a different "path" property.

  3. To move, just change the "path" property.

If you must insist on hierarchical, just mimic how a file system does copy-paste and move.

The copy is easy. A GET for the resource to copy.

To paste, a POST, because you are creating a new resource, a new URI.

If you need to do a move, you probably need to DELETE the old resource.

If you want, you can specify a location in the delete request, allowing the server to redirect users looking for the moved resource at its old location.

0

I would have it so that the user executes PUT command to execute the action.

So something like a variable in the form data is contains the correct action to perform.

kemiller2002
  • 113,795
  • 27
  • 197
  • 251
  • -1: That's no less an RPC call than the original question. He asked for a RESTful way and putting the action in the body isn't. – Greg Beech May 13 '09 at 18:11
  • Actually I think it is. REST signifies that the object is located by the URL location and can always re-access that item by going to that URL. The POST event shows that the calling object wishes to perform an action on that item. – kemiller2002 May 13 '09 at 18:17
  • However, RESTful indicates that the HTTP verb (GET, PUT, DELETE) etc. indicates the action to perform. Putting the action in a POST body is RPC-style, not RESTful. – Greg Beech May 13 '09 at 18:21
  • I see what you are saying. But if you are going to potentially do multiple things with the PUT command (I misspoke when I said post) you have to tell it which action to do. – kemiller2002 May 13 '09 at 18:32
  • 2
    True - but then that isn't RESTful, it's RPC-style. And you're right, it can be necessary to have RPC-style pockets within a predominantly RESTful API as sometimes there's simply no other way you can model what you're trying to do. But in this case the GET/PUT combination shown in one of the answers would allow it to be modeled RESTfully just fine. (PS: I removed the -1 vote because I think the answer plus comments are useful to the question). – Greg Beech May 13 '09 at 18:35
  • Yeah your right, after I saw the other response, it became clear that was the obvious answer. – kemiller2002 May 13 '09 at 18:42