如果对象之间没有 id，RESTful url 是否有效？
我有两个 RESTful API 设计问题。假设我有一个水果摊网络应用程序。我想返回有关我携带的所有水果以及这些水果的数量的信息，我使用以下方法执行此操作：
http://myfruitstand.com/fruits
问题 1： 如果我有 10 个橙子，那么我想我可以通过以下方式获取有关特定橙子的信息：
http://myfruitstand.com/fruits/oranges/3
但是上面的 url 是否是 RESTful——我不需要在“fruits”和“oranges”之间添加一个 id 来符合 REST 标准吗？或者这个带有 'fruits' 的 url 是否立即跟随子类 'oranges' 好吗？
问题 2： 同样，如果我想有一个关于我的橙子（不是特定的橙子）的讨论论坛，我可以把它放在这里吗：
http://myfruitstand.com/fruits/oranges/comments
同样，上面的 url 是 RESTful，因为“橙子”和“评论”之间没有 id（这里是 id，当然，这意味着要讨论某个特定的橙子，而我不希望这样）？在这里，不存在紧随“评论”的“橙色”的子类理性。
预先感谢，查克
I have two RESTful API design questions. Let's say I have a fruitstand web app. I want to return information about all the fruits I carry and the counts those fruits, and I do it with:
http://myfruitstand.com/fruits
Question 1:
If I have 10 oranges, then I'm thinking that I can get information about a particular orange with:
http://myfruitstand.com/fruits/oranges/3
But is the above url RESTful--don't I need an id between 'fruits' and 'oranges' to conform to REST standards? Or is this url with 'fruits' being immediately followed with the subclass 'oranges' okay?
Question 2:
Similarly, if I want to have a discussion forum about my oranges (not a particular orange), can I put it here:
http://myfruitstand.com/fruits/oranges/comments
Again, is the above url RESTful since there's no id between 'oranges' and 'comments' (an id here, of course, would imply a discussion about a particular orange and I don't want that)? Here, there's no subclass rational of 'oranges' being immediately followed by 'comments.'
thanks in advance, Chuck
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通过资源集合/id 对构建会更加 RESTful，例如 /fruits/:id1/items/:id2，其中 id1 = Orange，id2 = 3
那么如果您丢失了第二个问题的答案也是正确的橙色上的“s”，因为您将橙色视为资源的实例而不是资源集合。
例如http://www.slideshare.net的第48张幻灯片/Wombert/phpnw10-designing-http-services-and-restful-interfaces
It would be more RESTful to construct by resource-collection/id pairs, e.g. /fruits/:id1/items/:id2, where id1 = orange, id2 = 3
Then the answer to the second question would be also correct if you lose the 's' on oranges, as you are treating orange as an instance of a resource and not a resource collection.
e.g. slide 48 of http://www.slideshare.net/Wombert/phpnw10-designing-http-services-and-restful-interfaces
我自己刚才一直在问有关 RESTful 风格的问题。但我的看法是：
如果是水果店，不是就暗指“水果”吗？简单地说：
/oranges/{id}
或者：
/fruits/{id}
这只是橙色类型的水果。
/fruits?type=orange 可以返回橙子列表
Just been asking questions about RESTful style myself. But my take on this is:
If it's a fruit store, isn't 'fruit' implied? How about simply:
/oranges/{id}
Alternatively:
/fruits/{id}
Which is just a fruit of type Orange.
/fruits?type=orange could return you a list of oranges
是的，只要是确定性的，所有的 url 都是安全的。 Restful 更多的是关于您正在使用的 http 方法（DELETE 例如删除，POST 编辑，GET 读取，...）。
Yes all urls are restful as long as they are deterministic. Restful is more about the http-methods you are using (DELETE for instance to delete, POST to edit, GET to read, ...).
只要您的网址对您的对象组织进行建模，那么我相信您就可以开始了。
另外，我个人的感觉是，如果您发现需要稍微偏离任何规范才能满足您的应用程序需求，那么这是合理的做法。不要让这种“模型”的坚持妨碍工作的完成。例如，在 RESTful 上下文中，有时您执行与某些对象相关的操作，这些对象并不明确属于 DELETE/PUT/POST/GET 动词。为了保持完美的休息，你会把这些东西塞进去吗？
我现在躲在桌子后面，以免被那些安宁的大师/宗教主义者打昏，他们现在不可避免地会殴打我:)
As long as your urls model your object organization then I believe you're good to go.
Also, my personal feeling is that if you find a case where you need to depart ever so slightly from any specification to meet your application needs, that's a reasonable thing to do. Do not allow adherence to this sort of 'model' interfere with getting the job done. For example in the RESTful context, sometimes you perform actions related to some objects that just don't fall clearly under the DELETE/PUT/POST/GET verbs. Do you smoosh those things into there in order to maintain perfect RESTfulness?
I am now hiding behind my desk so as not to be knocked unconscious by the RESTful gurus/religionists that will inevitably beat up on me now :)