I'm building an API, that will be used by different logged-in (and not logged-in) users of different roles/types (e.g. reader, editor, admin etc.).
Is something like /users/{user_id}/path/to/data a correct RESTful way to define the are the user has access to? Or maybe just /{user_id}/path/to/data? Or should it be a body/query param like /path/to/data?user_id={user_id} or /path/to/data?user_token={user_token}? Or is the header the correct place for that information?
How should the user be provided to the API server REST-conform way?
Note: It's not about subresources of the user resource, e.g. addresses (if we define this as a subresource of user). Since this case is clear /users/{user_id}/addresses/{address_id}. The question is in general about the whole data the user may access.
答案 0 :(得分：4)
我认为用户ID在URL中没有非用户相关内容的位置 - 您描述的内容最好用/ path / to / data /表示，而user_token或类似内容应该在标头（例如，auth标头中的JSON Web Token），不在URL中，也不在查询参数中。
如果用户无权访问指定的资源，系统应响应授权错误HTTP响应。
您所描述的结构仅在资源是用户的子资源时才适用，并且正如您所指出的那样，您所询问的资源并非如此。
答案 1 :(得分：3)
虽然我完全同意马克之前的回复，但它直接跳到答案而没有解释为什么它是对的。它也没有解决一些对URI方案的需求提出质疑的评论，所以我想我会尝试在这里为骨头添加一些肉。
我认为这个问题背后有两个基本问题，所以我会轮流接受它们。
URI命名原则
虽然严格的REST一致性并不严格要求，但人们普遍认为有意义的名称会增强RESTful API，因此存在很多争论，但没有任何东西可以完全编写您必须做出的决定。
通常，我发现principle of least astonishment（POLA）有助于创造最佳设计。对于RESTful API，这意味着值得尝试为您所代表的数据找到URI的自然匹配。如果你正在寻找一个声音，这通常意味着使用名词而不是动词。这是一个很好的探索here。
然后您就会遇到数据的自然表示实际存在的问题。自然范围是一个高级URI，关联文档中包含大量数据，许多URI中包含非常少的数据，或者实际上是两者的混合，您可以从构造的URI中找到更详细的信息，类似于某些内容比如XPath？
这个通常归结为您的应用程序的要求。某些应用程序需要具有细粒度访问权限，以便许多客户端可以同时更新同一URI树的子部分;其他人可能需要一个包含复杂文档的URI，以避免数百个请求出现性能问题。一般来说，我尝试从最简单的实现开始 - 例如单个文档 - 直到我发现需要更复杂的文档。
如果仍然没有解决你的命名困境，你就会陷入相关对象的棘手主题，这与好的OO或关系数据库设计有很大的相似之处。再次应用POLA，我相信如果您想要在仅中检索的数据在路径的较高元素的上下文中有意义，则应该只使用/some/path/to/data。
以上述标准为例：显然您的用户可以拥有包含地址的个人资料信息。这个地址可能只在用户上下文中有意义 - 它是他们的地址。就其自身而言，它基本上没有意义（除非您出于某种原因维护地址数据库）。
现在让我们进一步举例，假设您正在创建类似StackOverflow的内容，并且每个用户都能够发布问题和答案。用户是否有问题列表是否有意义？是的，但是......通过首先寻找用户来限制系统的所有用户是否有意义找到这些问题？当您想要以自己的方式访问问题时会发生什么 - 例如显示最新的50个问题，找到任何未解答的问题等？很明显，有些用例意味着将问题提取到与用户不同的URI并存储某种关系相关因（例如，该用户提出的问题的ID列表）是有意义的。
在您的问题中应用相同的原则，我希望您同意将数据限制为源自用户的网址是错误的。
用户身份验证
任何严格的RESTful都需要无状态，因此应该避免基于会话的身份验证。那里有很多选择 - 其中许多已经在this site上详细探讨了，所以我认为我不能或应该在这个主题上添加更多内容。您应该查看SSL的使用以及建议的各种HTTP身份验证方案。