我正在尝试找出具有 Multi-Tenancy 支持和共享资源的应用程序的 url 结构的“正确”实现。
资源:用户、项目
URL 架构为
host/api/tenant_id/resource[/id][/subresource][/id]
用户 A(宽度 id = 1)在以下位置获取他的项目集合
GET http://example.com/api/1/projects/
用户A创建一个新项目，可读
GET http://example.com/api/1/projects/2
现在，用户 A 向另一个用户 B (id = 2) 授予对项目 2 的访问权限。 用户 B 希望通过以下方式查看与其帐户相关的所有项目的集合:
GET http://example.com/api/2/projects/
除了用户 B 自己创建的项目之外，共享项目 (id = 2) 是否也应该在此集合中？或者对于共享资源有更好的命名结构吗？
最佳答案
对于 RESTful 架构来说，专注于 URL 结构的设计实际上是不行的。罗伊·菲尔丁:
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server).
另请参阅this answer .
对于您的具体问题，我将返回用户有权访问的项目的(基本上是任意的)超文本链接列表。这些链接将包含明确的属性，以明确该项目是否由用户“拥有”或“可访问”。为了提高可读性，您可以将资源 URL 设计为
http://example.com/user/{user id}
http://example.com/project/{project id}
GET http://example.com/user/2 后用户的表示将包含链接列表，例如
<a href="http://example.com/project/1" class="owned"/>
<a href="http://example.com/project/2" class="access-permitted"/>
HATEOAS原则是 REST 所固有的，并且使得大多数“我如何设计我的 URI”问题变得过时:
The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers. A REST client needs no prior knowledge about how to interact with any particular application or server beyond a generic understanding of hypermedia.
关于api - 具有 Multi-Tenancy 和共享资源的 RESTful API，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28806186/