Question

我正在设计一个REST API，尽管我在搜索了许多最佳实践指南，但我发现很多与 最佳实践 有关的处理POST所需的表示结构与从GET返回的相同表示结构之间的差异。

对于虚拟GET表示，

user可能如下所示：

{
    "id": 1234,
    "created": "2012-04-23T18:25:43.511Z",
    "username": "johndoe@example.com",
    "name": "John Doe"
}

但是，同一虚拟POST表示的user无法指定某些属性（即id和created）：

{
    "username": "johndoe@example.com",
    "name": "John Doe"
}

显然，这是一个过于简化的示例，但鉴于用户无法指定某些字段（并且可能并不总是明显哪些与应用方法相关）是 最佳实践 为每个创建单独的表示或期望最完整的版本并在服务器上透明地处理数据差异？

尽管明显易于单一表示并处理差异服务器端，但我担心如果用户不清楚哪些值可以指定（或使用{{更改），这对用户来说将是一次糟糕的体验。 1}}例如）。如果趋势是创建单独的表示，是否有应用于表示定义的命名约定？

e.g。传入用户为PUT，传出用户为i_user。或o_user和user_full或user_min和user等。

更新：我过于简化的示例可能没有正确说明问题。想象一下具有50个属性的表示（例如服务器表示及其所有监视属性--cpu，ram，temp，storage_drive_a，storage_drive_b，file_permission等）。在这50个属性中，30个是只读属性，其中20个是值可以设定。

Answer 1

首先，POST方法的最终语义由目标资源决定，而不是由HTTP协议决定，与其他方法一样，因此您的POST方法可以执行任何您想要的操作，只要您正确记录，并且您没有复制已经通过其他方法标准化的功能。

因此，简而言之，为POST和GET方法设置不同的代码并没有错。

然而，在这种情况下要求最佳实践是没有意义的，因为定义表示格式的是所使用的媒体类型，而不是方法，但是大多数互联网上所谓的REST API使用通用媒体-types用于所有内容和客户端依赖于URI语义来了解他们正在处理哪些资源，而这些资源根本不是RESTful。基本上，当事情正确完成时，您要求在REST中确实存在的问题的最佳实践。

因此，要回答您的问题，您可以使用不同的媒体类型进行不同的表示 - 例如您的完整用户表示可能具有媒体类型application/vnd.mycompany.user.full.v1+json，简化的用户表示可能具有媒体类型application/vnd.mycompany.user.min.v1+json - 或者您可以使用application/vnd.mycompany.user.v1+json之类的单个表示形式，并且此媒体类型的文档可能会详细说明某些属性是否存在，或者如果未提供则可能具有默认值。您的POST方法将需要一种媒体类型才能工作，如果客户端在415 Unsupported Media Type标头中发送任何其他内容，则会以Content-Type响应。同样，客户可以使用Accept标题选择所需的表示。

正如您所看到的，当您真正使用REST时，您所要求的并不是问题，而不仅仅是将其用作HTTP API的流行语。

处理POST和GET之间的RESTful表示结构差异

1 个答案: