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