请求属于集合的对象的首选 REST url 模式是什么？
我们有带有一系列通道的 REST API。请求通道时，应该使用通道集合端点还是通道对象端点？
/channels/{id}/ // this?
/channel/{id}/ // or this?
当涉及到主干模型 URL 属性时，我希望它能够与backbone.js 尽可能无缝地工作。
We have REST API with a collection of channels. When requesting a channel, should I use the channels collection endpoint or channel object endpoint?
/channels/{id}/ // this?
/channel/{id}/ // or this?
I want this to work as seamless with backbone.js as possible when it comes to backbone model URL attribute.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
大多数有关 Restful API 的书籍建议您使用单数作为端点。您可以从那里获取集合以及对集合的单个实例的操作。
打电话：
等等。然而对于 Backbone 来说这没有什么区别，因为您可以根据需要自定义 URL 行为。
Most books about restful API's suggest that you use the singular for your endpoint. You get the collection from there as well as operations on single instances of the collection.
Calling:
and so on. Nevertheless for Backbone this makes no difference as you can customize the URL behavior as you wish.
末尾的
/不应该对偏好产生影响（如果这样做的话，对用户来说太混乱了！），虽然您可以根据需要使用单数或复数，但请在整个应用程序中保持一致让个体成为集合的子元素。将集合视为个人目录。The
/on the end should not make a difference for preference (too confusing for users if it does!) and while you can use singular or plural as you choose, be consistent throughout your app and make the individuals children of the collection. Think of the collection as being like a directory of individuals.在某些时候，这确实只是偏好。有些人认为 REST api 的定义应该始终是复数。主要是我总是对
/channel作为一个列表感到恼火，所以我自然倾向于以复数/channels来处理所有内容。这与他们告诉你在表格设计中要做的事情是相反的：将一切都视为单一的。归根结底，只要保持一致就会让许多使用您的 API 的人感到高兴。At some point its really just preference. Some people argue the definition of REST apis should always be plural. Mainly I always get annoyed with
/channelbeing a list, so I naturally gravitate to treating everything in the plural/channels. Which is backwards from what they tell you to do in table design: treat everything as a singular. At the end of the day, just being consistent will make many people that use your apis happy.