我正在构建一个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因为我不是要创建新资源 - 我特别不希望创建一个。
我做错了吗？
I'm building a RESTful API that exposes my application's users as users.
My application also features 'documents' and each user has access to specific documents. I'm thinking the natural way to represent that is by exposing the accessible documents through users/{user-id}/documents.
However, from a usability perspective, it's important for my clients to be able to fetch (and modify) the users that have access to a specific document. Because of that I'm considering 'reversing' this representation to documents/{document-id}/users.
Do these (and especially the latter) seem like proper ways to model this relationship? If I do go with such a solution, how do I model 'granting access to a document'?
I'm leaning towards PUTing a pre-existing user (presumably acquired by GETing users) into documents/{document-id}/users/{user-id}. That seems unsatisfactory however, as I'll be doing an 'update' operation not to actually update the resource but to insert it into a collection. It is especially problematic in terms of semantics as I expect my server-side to ultimately not take into account the complete, sent user representation but rather only cross-reference the id with ids of pre-existing users in order to create an association.
On the other hand, I can't POST into documents/{document-id}/users as I'm not aiming at the creation of a new resource - I specifically don't want one to be created.
Am I doing it wrong?
最满意答案
用户并不真正属于文档资源，对吧？ 您真正说的是这些用户可以访问此文档。 因此，/ 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" } ] } ] } }The users don't really belong to the document resource, right? What you're really saying is these users have access to this document. So what should probably be returned from /documents/{document-id}/users is not a direct representation of the user entity, but instead some kind of representation of the user's permission to the entity. Perhaps inside of that representation is a link to the full user itself.
So, if you were returning the Collection+JSON media type, maybe you'd have something like:
{ "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" } ] } ] } }更多推荐
发布评论