我有一个Rails应用程序需要将数据库中的值作为Web服务公开 - 因为我正在使用Rails 2.x，我将使用REST（或至少尝试）。假设我的资源是Bananas，我想要公开几个子特征，请考虑这个：
- /banana -> give a summary of the first 10 bananas, in full (all characteristics)
- /banana/?name=<name> -> give all characteristics for banana named <name>
- /banana/?number=<number> -> give all characteristics for banana number <number>
- /banana/?name=<name>/peel -> give peel data for banana named <name>
- /banana/?number=<number>/length -> give length data for banana number <number>
我不想要搜索ID，只搜索名称或编号。我有大约7个子特征要揭露。这是RESTful吗？
感谢您的反馈！
答案 0 :(得分：10)
Wahnfrieden所说的是Hypermedia as the Engine of Application State（HATEOAS） - 由Fielding定义的REST的核心约束。
简而言之，REST应用程序客户端永远不会自己构造URI。相反，它们遵循应用程序提供的URI。因此，诸如您所询问的URI模板充其量只是无关紧要的。如果您愿意，可以使它们符合系统，但REST没有说明您的URI需要如何查看。如果您愿意，可以安排它，以便系统中的每个资源都可以从http://example.com/ {hash}获得。
发布URI模板，例如您在问题中讨论的模板，会在您的应用程序和客户端之间引入紧密耦合 - 这正是REST试图阻止的。
理解超媒体驱动的应用程序的问题在于，几乎没有人以这种方式实现或记录他们的“RESTful”系统。
通过浏览器考虑人与服务器之间的交互可能会有所帮助。人类只知道服务器通过浏览器提供的内容和链接。这就是构建RESTful系统的方式。如果您的资源没有公开链接，那么它们可能不是RESTful。
优点是，如果您想要更改URI系统，例如，通过查询参数而不是嵌套URL公开Banana“Peel”属性，您可以随时执行此操作并且无需客户端代码需要改变，因为他们没有为自己构建链接。
有关在REST中包含超文本驱动约束的系统示例，请查看Sun Cloud API。
答案 1 :(得分：7)
我会用这些：
首先，ReSTful URI的常见做法是/ object_name / id / verb，其中一些缺席（但按此顺序）。当然，这既不是必需的，也不是预期的。
如果您的所有姓名都不是数字，则不必在/ banana / name / blah中明确拥有name。事实上，如果有的话，最好将id作为标识符：/ banana / id / 123 / peel。希望这会有所帮助。
答案 2 :(得分：2)
参数只能用于表单提交。
此外，URI命名模式与REST完全无关。 REST的目的是通过超文本，而不是带外约定，并且仅从极限数量的入口点使相关资源可被发现。因此，您的/ bananas /入口点可能会提供10个香蕉的摘要信息，但它还必须为每个香蕉的详细信息资源提供URI，以及获取下10个香蕉的摘要的URI。其他任何东西都只是RPC。
答案 3 :(得分：0)
REST中的优秀做法是不使用查询参数，因为查询参数不属于URL，而在REST中，所有资源都应通过URL进行寻址。
在您的示例中/ banana /？name = name 应该是/ banana / name ，因为您指的是具体资源。
即使我认为/ banana /？number = number / length也不是好的REST样式，因为当你应该使用/ banana /
HTH。
答案 4 :(得分：0)
具有查询字符串的url中的路径的更多选择形式是复数形式，因为可能在结果中返回多个项目。在这种情况下，香蕉，如香蕉？颜色=黄色，听起来更合适。 另一方面，单数形式香蕉，如香蕉/ 123，在获取特定资源的表示时，当其标识符已知且不需要查询字符串时，它是很好的。