我正在开发一个网站，其中有很多页面不属于我对RESTful设计的有限理解，基本上是：
Create, Read, Update, Delete, Show, List
这是一个问题：当页面没有整齐地落入CRUD / show / list时，标记动作/路线的好系统是什么？我的一些页面一次有关于多个表的信息。我正在建立一个网站，在登录后为一些客户提供“基地”。它没有给他们任何关于他们自己的信息，所以它不应该是，例如，/ customers / show / 1。它确实有关于公司的信息，但网站上还有其他页面以不同的方式执行此操作。遇到这些情况后你会怎么做？这个“家庭基地”向客户展示，它主要有关于公司的信息（但不是唯一的）。
第二种情况：我在客户和公司之间有一个名为'Matchings'的表。这些匹配在网站的不同部分以完全不同的方式访问（不同的布局，不同的CSS表，访问它们的不同类型的用户等等。它们不能全部匹配/显示。标记其他的最佳方式是什么？
非常感谢。 =）
答案 0 :(得分：7)
我当然不是专家，但是如果你重新考虑你的资源并将它们更严格地视为'名词'或至少是数据列表，那么将任何所需的动作放入GET，POST，PUT和删除。例如，您有一个/customers/资源可以为每个客户提供/customers/{username}/资源。也许这给了他们关于他们自己的信息您可以将/homebases/{username}/或/customers/{username}/homebase/作为您的家庭基础资源。据推测，您主要通过GET访问该homebase资源，如果有任何要更新的话，可以访问POST（由于它是一个聚合资源，我不希望在家庭基础或仪表板上使用它。）
对于“匹配”，您可以使用类似/matchings/{customer},{company}/的内容（是的，允许使用逗号和分号。逗号通常表示这两个部分依赖于顺序，分号表示与顺序无关，但没有规则） 。从该资源，您可以让GET读取，显示和列出您需要的任何数据（包括作为GET请求主体传递的可选查询参数），POST更新，PUT创建和删除删除。使用GET中传递的参数，您还可以请求相同数据的不同视图。当然，您可以拥有匹配的子资源，例如/matchings/{customer},{company}/invoices/{invoice#}/。
顺便说一句，我喜欢“RESTful Web Services”（2007 O'Reilly）这本书。
我希望这样做有所帮助。 =）
答案 1 :(得分：3)
我认为聚合和复合视图是一个严重的问题。我不得不处理homepage问题，这个问题违背了我所知道的所有RESTful。
我的解决方案是将主页或仪表板视为资源本身，但只有GET操作才有意义的资源。主页上的POST / PUT / DELETE像往常一样被定向到特定资源。
相比之下，匹配似乎是一个更容易驯服的问题。从您的描述看，它似乎是客户和公司之间的简单映射，您可以根据查询字符串参数对其进行参数化。/matchings?companies=X,Y,Z&locations=NY,CA,TX
答案 2 :(得分：2)
通过RESTful设计，我认为你的意思是RESTful Web服务，因为基于REST的架构具有更广泛的意义。
要考虑的主要问题是基于REST的体系结构几乎在所有情况下都依赖于HTTP协议。由于HTTP指定了一组方法，因此有时这些方法用于创建所谓的RESTful Web服务。
但RESTful Web服务不遵循任何具体标准（与SOAP不同）。通常使用：
创建，读取，更新和删除（CRUD）是任何持久存储的基本功能。
很容易看出，在常见的RESTful Web服务中，每个HTTP方法都用于匹配其中一个基本功能，但重点是：它不一定是这样。
还有其他需要考虑的事项，URL映射就是其中之一（因为这是你问题的关注点），安全性是另一回事。 POST请求在HTTP正文中发送请求的内容（可以加密），但GET请求将其发送到URL中，供所有人查看。
如果想要开发安全（加密）的RESTful Web服务，可以将所有请求设置为HTTPS POST，然后在请求中指定，要执行哪个CRUD操作以及使用哪些资源。
人们还可以将CRUD概念扩展到更广泛的范围，事实上，几乎在每个应用程序中都必须这样做。
记住CRUD只是所有其他操作可以构建的四个基本操作。您没有必须遵循的标准，您可以根据您的上下文中有意义的内容指定自己的协议，并牢记所有相关注意事项（安全性，URL等）
特别是关于你的问题，你可以有自己的行动，比如show_by_x，show_by_y等.REST警察不会来抓你： - ）
答案 3 :(得分：0)
REST和ORM是两个不同的东西，因为即使你有一个名为User的模型，你也需要拥有一个用户资源。应在rails控制器级别管理资源
将资源视为模块/部分
例如：您可能希望用户在登录后登陆仪表板页面（并说您有两类用户管理员和普通用户），因此您可以将两个资源命名为
admin_dashboard uer_dashboard
并且两者都可能只有读取动作
第二种情况：
如果可能的话，考虑使用上面的示例（根据不同的用户级别使用不同的资源）
我不是REST大师，但希望这会有所帮助：D
欢呼声， sameera