Api 我的URI应该如何构造为RESTful？

我开始为我的项目开发一个公共API，我想让它成为RESTful。
我一直在看一些关于一些API（比如twitter）不是真正的RESTful的文章，我想尝试使我的API尽可能的RESTful（看起来并不是那么简单：）

目前有一件事我正在考虑，假设有两个资源，用户和电影，每个用户都有一个电影列表，我想创建一个REST api，为当前连接的用户获取所有电影，正确的设计方法是什么？
（XXX是某种身份验证令牌-我还没有决定要实现什么身份验证）

获取/观看电影？令牌=XXX

获取/users/XXX/movies

或者一起做点别的

---

另外，如果有人能给我一本关于这个主题的好书，这将帮助我尽可能地创建RESTful公共API，这将是一个很大的帮助

我非常喜欢Leonard Richardson的Restful Web服务。他解释了REST，一些站点如何滥用它，如何正确使用它，何时使用查询字符串，而不是将信息放入URI路径。他也谈到了身份验证，但他对这个话题有点简短。他花了很多时间解释为什么REST比SOAP好——我很喜欢它，但其他评论家似乎觉得它太过分了。他在大多数示例中使用Ruby/Rails

在您的两个示例中，我更喜欢“GET/users/XXX/movies”而不是第一个。使用查询字符串有利于搜索或可选参数。类似于google.com/？q=batman或/users/XXX/movies？page=2。因为您正在查看特定用户的电影，所以URI与该结构匹配是有意义的，选项2就是这样做的

有些站点并不是真正的RESTful，因为它们提供了如下方法

GET /GetUser?token=XXX
GET /SaveUser?token=XXX&name=YYY

真正的RESTful服务将遵守现有的HTTP命令，并在资源而不是功能上操作。根据这本书，如果您遵循HTTP协议，您通常不需要在服务名称中使用“get”或“save”之类的词——它们是由HTTP提供的

GET /user/XXX
PUT /user

---

希望这有帮助。我没有什么好的网络资源，但我建议尝试一下这本书。

阅读罗伊·托马斯·菲尔丁的博士论文，题为《对我来说是理解REST架构风格的好方法》。一开始似乎令人望而生畏，但它充满了可以帮助您设计更好的API的见解。

问“做X的正确方法是什么”是在问一个主观的答案，很可能导致这个问题被关闭。你们能把你们的问题重新表述成一个有明确事实答案的问题吗？嗨，悲剧演员，我想既然其余部分都有特定的结构和规则，那个么只有一个（正确的）答案，我错了吗？我应该重新措辞标题还是整个问题写得不好？你能给我举个例子吗，因为我真的不知道我能改变什么：/是的，rest不是一条真正的路径，它是一组约束，你的URL看起来不是其中之一（只要它代表一个名词而不是某种动作/动词）@Nicholas你的评论就是我想要的：）我的方法似乎是错误的。谢谢@悲剧我编辑了标题，希望这是更好的…我完全同意这个答案。尤其是我更喜欢“GET/users/XXX/movies”这句话，而不是第一句。使用查询字符串适合搜索或可选参数Hanks Michael，我将尝试一下这本书。另外，可以将auth令牌作为头传递还是应该在URI中传递？如果可以，请尝试使用HTTP现有的身份验证方案之一：带有基本或（更好）摘要令牌的授权头，但是如果不能，并且可以从客户端将其作为头传递（某种脚本需求），那么请务必这样做。保持URI干净。只要确保在用户未进行身份验证时返回401，这样缓存就不会保存失败响应但是如果我想使用头或内置身份验证，那么URI将如下所示：GET/users/movies，当前用户将从auth头中获取，我看到了关于这种URI类型的抱怨，它不是RESTful，因为同一个URI为不同的人返回不同的结果（参见这里）——我误解了？您可以通过将URI保持为/users/keisar/movies来处理这个问题。如果只允许keisar查看他的电影，那么URI保持不变，但是您添加了身份验证——因此/user/keisar/movies将起作用，但是/users/michael/movies将被拒绝。如果用户可以观看任何其他用户的电影，则URI仍然相同，但不需要身份验证。您没有使用身份验证来确定要返回的数据；您正在使用它来确定用户是否可以查看请求的资源。