Question

我正在为这项服务设计一个资源，该资源具有一组可变属性和一组不可变属性（例如，status由服务生成，而不是客户端可能更改的内容。

我需要在对GET资源请求的响应中包含此内容，但如果有人随后发送带有PUT请求的资源，我不知道该怎么办。

强制调用者知道哪些属性是不可变的感觉是错误的，但是静默丢弃更新也感觉不正确。使用更新的资源响应PUT请求可能会解决问题，但它不完美，因为调用者不应该对其请求和服务的响应进行区分，以确定是否接受了属性。

关于正确前进方向的任何想法？

P.S。我看了How should I update a REST resource?，但它与这个问题不同，并促进了过于繁琐的API设计。

Answer 1

我建议遵循http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10的指南。 HTTP 409的定义包括以下内容：

1）由于与资源的当前状态发生冲突，无法完成请求。

2）响应主体应该包含足够的信息，供用户识别冲突的来源。

因此，对不可变属性的更改是资源状态的问题，HTTP 409似乎适用。

至于如何将问题传达给客户，指导似乎是在回复机构中包含详细信息。

您还可以在表示本身（在GET上）传达属性的可变性。例如。

<MyObject>
   <Foo>17</Foo>
   <Bar readOnly="true">22</Bar>
   ....

Answer 2

您可以设计API的响应，以便只读属性实际上与可变属性分开。例如：

{
    id: 42,
    status: "terrific",
    properties: {
        // mutable properties here
    }
}

我有写入和使用过的API都可以做到这一点，而且效果很好。

Answer 3

将HTTP PATCH与JSON-Patch文档一起使用 - 这使您可以准确地指出要修改的属性。请参阅http://tools.ietf.org/html/rfc6902。

但PUT的不可变和可变元素都没有错。服务器可以随意忽略它不希望进行更改的内容。我在这里写了一篇关于这个主题的深入讨论：http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html

Answer 4

另一种解决方案是将只读字段作为HTTP标头发送回。这样，您可以使GET和PUT资源保持相同。

如果只读字段主要是“技术”字段，例如 createTime ， updateTime 等，状态，则这可能最有意义。也可以被视为技术领域？