REST API for resource cloning

Question

I am writing a YAML document using swagger to develop a RESTful API method for cloning a resource. I have several options and don’t know what would be better. Please can anyone advise?

Options:

• The disclaimer of cloning a resource object to the consumer (where the consumer assigns values ​​to the properties of the new object and then creates a new object), the process should consist of two API requests: GET for the resource for the original object, and then POST for this resource to create a new one. It seems that the consumer has too much responsibility .
• Using HTTP WebDAV extensions, which provides the COPY method ( see here ). It would seem that this is exactly what I would like to do for cloning. However, I would like to adhere to standard methods as much as possible
• POSTing to / {resource}? resourceIdToClone = {id} , where resourceIdToClone is an optional parameter. This would contradict the API path that I already have for creating the resource, where I add the schema to the POST body. That would mean using POST for / {resource} / to create and clone, and that would violate SRP.
• Adding a new resource called "CloneableResource" and doing POST to / CloneableResource / {resource_type} / {resource_source_id}. . An example of sheep cloning, you should do a POST for / CloneableResource / Sheep / 10. Thus, it would be possible to use standard HTTP methods, there would be no conflict with other resource paths (or with SRP violation). However, I would add a new and potentially superfluous type to the domain. I also can’t come up with a scenario where a consumer would like to execute anything other than POST to this resource, so it seems to me like a smell of code .
• GET vs / resource / {id}? method = clone . One of the advantages here is that an additional resource is not required, and it can be specified with a simple optional querystring parameter. I know that one of the risks here is that it can be dangerous to provide post or delete functions using the GET method if the URL is on a web page because it can be crawled by a search engine.

Thanks for any help!

Answer 1

Under the influence of the project requirements and the range of preferences among my team members, option 1 will serve us best at this stage.

• In accordance with standard HTTP methods, my API is simplified and refined
• There will be a single, consistent approach to resource cloning. This outweighs the problem that I have, designating the cloning work for the consumer.

Answer 2

Most of these options are great choices. A lot of everything is just your choice of style at the end. Here are my comments on each of your options.

• Disclaimer for cloning a resource object to a consumer
  In general, I have no problem with this solution. This parameter is very simple for the user to understand and implement. This might be better than coming up with some proprietary cloning features that your users should learn how to use.

• Using WebDAV HTTP Extensions that Provide the COPY Method
  I like to stick to standard methods. I would not use COPY , but I would not be shocked if you did.

• POSTing to / {resource}? resourceIdToClone = {id}
  This is the perfect solution. From a REST perspective, you really have no conflict with the rest of your API. A URI with a request parameter identifies a different resource than a URI without a request parameter. Request parameters is a URI function for identifying resources that cannot be referenced hierarchically. However, it can be difficult to separate them in your code due to the way most REST frameworks work. You can do something similar to this, with the exception of a hierarchical URI, such as /{resource}/clone . You can send a POST to this URI and pass resource_source_id in the body.

• Adding a new resource called "CloneableResource" and doing POST to / CloneableResource / {resource_type} / {resource_source_id}
  There is nothing wrong with this approach in terms of REST, but I think adding a new type is unnecessary and cluttering the API. However, I do not agree with your intuition that there may be a problem with a resource that only has a POST operation. It happens. In the real world, not everything fits perfectly in GET, PUT or DELETE.

• GET vs / resource / {id}? method = clone
  This is the only option that I cannot indulge. From your description, it seems that you already understand why this is a bad idea, so I'm not sure why you are considering this. However, all you have to do to make this a good solution is to change the GET to POST. Then it becomes very similar to solution No. 3. A URI can also be hierarchical rather than using a query parameter. POST /resource/{id}/clone will work just as well.

Hope this was helpful. Good luck with your decision.

Answer 3

If you want to COPY a resource, then yes, COPY is the obvious choice.

(and yes, it would be useful to derive the definitions of COPY and MOVE from RFC 4918 to unravel them from WebDAV).