假设我有一个网站，用户可以在其中上传和展示他们的图片。该用户的单张图片的 RESTful url 如下所示：
http://api.gallery.com/users/{user-id}/images/{image-id}
但是 image-id 本身已经是唯一的，所以这个 url 已经足够好了：
http://api.gallery.com/images/{image-id}
从 REST 的角度来看，第一个是有利的，但是我应该验证，这张图片真的来自这个用户，因为有人可以更改 url，将用户 ID 更改为其他人的。在后一种情况下，我不需要添加此检查，这意味着更少的处理时间。
在这种情况下仍然首选 RESTful 吗？
简而言之，两者都是首选；两者都可能返回相同的“事物”，但“上下文”不同。
让我们看一下您的网址：
/users： 所有用户/users/1: 用户 #1/users/1/images：所有用户#1的图片/users/1/images/1：用户#1的图片#1上述所有 URL 都围绕“用户”资源。它是“所有用户”、“一个用户”、“一个用户的图像”等。
/images: 所有图片/images/1: 图片 #1上述所有 URL 都围绕“图像”资源。它是“所有图像”或“一个图像”。
现在，从表面上看，这种区别似乎相对较小，但在构建 API 时，这种区别会对数据的使用方式产生很大影响。
例如，假设您想要获取用户#1 的所有图像的列表，哪个是首选？
/users/1/images
或者
/images?where=user.id eq 1
第一种形式准确地代表了我们想要的，更受限制，更容易理解，但是，这并不意味着我们不应该也支持第二种形式，因为查询的能力可能非常有用。
现在，如果您想获取图像列表及其关联用户怎么办？
/users/???
或者
/images?include=user
在这种情况下，第一个 URL 根本没有多大意义，因为我们试图获取图像列表，而不是用户，而第二个 URL正是我们想要的。
现在，关于安全性，理想情况下应该以对消费者完全透明的方式来完成。消费者应该能够说“我想要所有图像”。并且只收到他们有权访问的所有图像。如果他们尝试访问他们无权访问的特定资源，则应返回适当的 HTTP 错误代码。
我认为由于您所说的原因，第二个更RESTful。URL 是一个层次结构。用户 ID 并不是图像标识的一部分，那么为什么要让它成为标识符的一部分呢？
创建一个 /users/{user-id}/images 资源，该资源以 /images/{image-id} 的形式返回 URL 列表，以列出用户上传的图像，您将拥有两全其美的优势。
我认为这完全取决于语义和意图。您似乎在谈论受保护的资源，而不是公开可用的资源。在这种情况下，当使用更冗长的格式时，您的沟通会更加明确并且意外最少：
http://api.gallery.com/users/{user-id}/images/{image-id}
如果它是公共资源，那么它只能通过 image-id 来识别，那么较短的格式会更合乎逻辑：
http://api.gallery.com/images/{image-id}