Background
I am creating an API that allows clients to manipulate geospatial objects. These objects contain the location in the world (in latitude / longitude) and a lot of metadata. The actual API is pretty big, so I present a simplified version here.
Current API
Consider an API with two objects, functions, and attributes.
The endpoint of the /api/feature function is as follows:
{ id: 5, name: "My super cool feature", geometry: { type: "Point", coordinates: [ -88.043355345726, 43.293055846667315 ] } }
The endpoint of the /api/attribute . The attribute looks like this:
{ id: 3, feature_id: 5, name: "attr-name", value: "value" }
You can interact with these objects by sending HTTP requests to your endpoints using different HTTP methods, as you might expect:
GET /api/feature/5 reads function with identifier 5.PUT /api/feature/5 updates the function with identifier 5.POST /api/feature creates a new feature.DELETE /api/feature/5 removes the function with identifier 5.
The same goes for attributes.
Attributes are associated with functions using a foreign key (usually expressed as "functions have many attributes").
Problem
It would be useful to be able to make a copy of the function and all its metadata (all attributes that belong to it). The use case is more or less: "I just made this function and gave it a bunch of attributes, now I want the same thing ... but there." Thus, the only difference between the two functions will be their geometry.
Solution # 1: do it to the client.
My first thought was to just make it a client. Create a new function with the same name in a new location, and then repeat all the attributes of the source function by issuing POST requests to make copies of them on the new function. This, however, suffers from several problems. Firstly, it is not atomic. If a client Internet connection leaks out during this process, you will be left with an incomplete copy, which is lame. Secondly, this is likely to be slow, especially for functions with many attributes. Anyway, this is a bad idea.
Solution # 2: Add Copy Features to the API.
Performing server side copying in a single API call would be a better approach. This leads me to http://tools.ietf.org/html/rfc2518#section-8.8 and the COPY method. Being able to make a deep copy of a function in a single COPY /api/feature/5 request seems ideal.
Question
My problem here in COPY semantics is not quite suitable for the use that I imagine. Issuing a COPY request to a resource executes a copy of this resource to the destination specified in the Destination header. According to the RFC, Destination must be present, and it must be a URI that determines where the copied resource will end. In my case, the assignment for the copied function is geometry, which is clearly not a URI.
So my questions is: would json fill geometry with the Destination header of the COPY request with a specification distortion? Is COPY even the right thing to use here? If not, what are the alternatives? I just want to make sure that I implement this in most HTTP kosher ways.