混合REST API复数和单数为不同的资源？
REST API的复数形式更自然，更多用于例如/api/users或api/users/123 。
但对于一些资源并不自然，例如：
/api/login - 确切地/api/login一个用户 /api/profile - 获取登录用户的配置文件 这些资源永远不会用于我的应用程序中的更多对象/模型。
另一方面，我读到在资源名称中混合复数形式和单数形式并不是很好的做法（http://pages.apigee.com/web-api-design-ebook.html）。
所以我认为该怎么做：
/api/logins这样的愚蠢形式） /api/login或/api/profile ，这些资源始终与一个对象/模型一起使用。 什么是更好的方法？
对于定义RESTful API没有严格的指导原则，但我最清楚的是常识应该占上风。
因此，选项3：
不一致并且几乎所有资源都使用复数形式，因此需要一些特殊资源，如/ api / login或/ api / profile，这些资源始终与一个对象/模型一起使用。
是最合乎逻辑的。 当你认为“我需要资源X，这个URL将如何”时，你应该始终能够猜出URL？
我并不是说我更喜欢复数形式，但是如果你要用复数形式，你可以这样调和你的特殊单数形式：
GET /api/forms/login是HTML登录表单。 使用这种观点， login是表单集合中仅有一种形式的ID。
POST /api/forms/login是提交登录表单的地方。
GET /api/users/{id}/profile检索指定用户的配置文件。 这适用于很多情况，但不适用于匿名网站，即使在查看用户个人资料时用户的身份应保持隐藏状态，这可能会遗漏用户ID和真实姓名。
GET /api/profiles/{id}将配置文件实体与用户标识分离，并可用于匿名网站。
或者，您可以编写GET /api/users/current/profile或GET /api/sessions/current/profile ，因为服务器会回复与当前用户相关的内容。
REST（具象状态传输）基本上针对单个实体并对其进行CRUD。 所以使用单数对我来说更有意义。 但是如果你需要得到清单，那么复数是有意义的。 例如：
你想得到一个用户，然后有/ api / user / {id}
但是，如果你想获得用户的列表，那么有/ api /用户
链接地址: http://www.djcxy.com/p/7089.html上一篇: Mixing REST API plural and singular for different resources?