Question

我正在构建一个RESTful API，将我的应用程序的用户公开为users。

我的应用程序还具有“文档”功能，每个用户都可以访问特定文档。我想通过users/{user-id}/documents公开可访问文档的自然方式来表示。

但是，从可用性的角度来看，对我的客户来说，能够获取（和修改）有权访问特定文档的用户非常重要。因此，我正在考虑将此表示“反转”为documents/{document-id}/users。

这些（尤其是后者）看起来像是建立这种关系的正确方法吗？如果我确实采用这样的解决方案，我如何建模'授予对文档的访问权限'？

我倾向于将预先存在的用户（可能是通过GETing users获得）投入documents/{document-id}/users/{user-id}。然而，这似乎并不令人满意，因为我将进行“更新”操作，而不是实际更新资源，而是将其插入到集合中。在语义方面尤其有问题，因为我希望我的服务器端最终不考虑完整的，已发送的用户表示，而只是将id与现有用户的id交叉引用为了建立一个联想。

另一方面，我不能POST到documents/{document-id}/users因为我不是要创建一个新资源 - 我特意不想要创建一个

我做错了吗？

Answer 1

用户并不真正属于文档资源，对吧？您真正说的是这些用户可以访问此文档。因此，/ documents / {document-id} / users可能返回的内容不是用户实体的直接表示，而是用户对实体的权限的某种表示。也许在该表示内部是指向完整用户本身的链接。

所以，如果你要返回Collection + JSON媒体类型，也许你会有类似的东西：

{
  "collection":
  {
    "version":"1.0",
    "href":"/documents/document123",
    "items":
    [
      {
         "href":"/documents/document123/users/user3841",
         "data": [ 
                    { "name":"userName", "value":"John Doe", "prompt":"User Name" },
                    { "name":"permissions", "value":["Read"], "prompt":"User Permissions" }
                 ],         
         "links": [ 
                    { "rel":"user", "href":"/users/3841" }
                  ]
      },
      {
         "href":"http//whatever/documents/document123/users/user9387",
         "data": [ 
                    { "name":"userName", "value":"John Doe", "prompt":"User Name" },
                    { "name":"permissions", "value":["Read"], "prompt":"User Permissions" }
                 ],         
         "links": [ 
                    { "rel":"user", "href":"/users/9387" }
                  ]
      }
    ]
  }
}

RESTful API：为可以访问其他资源的资源集合建模

1 个答案: