HTTP:使用COPY方法可以接受,其中Destination标头不是URI吗？

Question

背景

我正在构建一个API,允许客户端操作地理空间对象.这些对象包含世界上的位置(纬度/经度)和一些元数据.实际的API相当大,所以我在这里提供了一个简化版本.

当前的API

考虑具有两个对象,特征和属性的API.

功能端点/api/feature如下所示:

{
    id: 5,
    name: "My super cool feature",
    geometry: {
        type: "Point",
        coordinates: [
            -88.043355345726,
            43.293055846667315
        ]
    }
}

属性端点是/api/attribute.属性如下所示:

{
    id: 3,
    feature_id: 5,
    name: "attr-name",
    value: "value"
}

您可以通过使用不同的HTTP方法向其端点发出HTTP请求来与这些对象进行交互,如您所料:

• GET /api/feature/5 读取id为5的要素.
• PUT /api/feature/5 使用id 5更新功能.
• POST /api/feature 创建一个新功能.
• DELETE /api/feature/5 删除id为5的要素.

属性也是如此.

属性通过外键与特征相关(通常表示为"特征具有许多属性").

问题

能够复制一个特征及其所有元数据(属于它的所有属性)将是有用的.用例或多或少,"我刚刚制作了这个功能并给了它一堆属性,现在我想要同样的东西......但是在那边." 因此,两个特征之间的唯一区别是它们的几何形状.

解决方案#1:让客户端做到这一点.

我的第一个想法是让客户做到这一点.在新位置创建具有相同名称的新功能,然后遍历源功能上的所有属性,发出POST请求以在新功能上复制它们.然而,这会遇到一些问题.首先,它不是原子的.如果客户端的互联网连接在这个过程中崩溃,你将留下一个不完整的副本,这是蹩脚的.其次,它可能很慢,特别是对于具有许多属性的功能.无论如何,这是一个坏主意.

解决方案#2:向API添加复制功能.

在单个API调用中执行复制服务器端将是更好的方法.这导致我http://tools.ietf.org/html/rfc2518#section-8.8和COPY方法.能够在单个COPY /api/feature/5请求中执行功能的深层复制似乎是理想的.

问题

在这里,我的问题是语义COPY不太适合我设想的用途.COPY在资源上发出请求会将该资源的副本执行到Destination标头中指定的目标.根据RFC,Destination必须存在,并且它必须是指定复制资源将在何处结束的URI.在我的例子中,复制特征的目标是几何,它绝对不是URI.

所以,我的问题是:将几何体的json填充到请求的Destination标题中是否COPY会违反规范？这COPY是正确的用法吗？如果没有,有什么替代品？我只是想确保我以最多HTTP-kosher方式实现这一点.

Answer 1

好吧，您需要一种方法使Destination成为URI（为什么这是一个问题）。如果您将 Destination 标头字段用于其他用途，则您不会按照规范使用 COPY。（顺便说一句，当前规范是 RFC 4918）