RESTful设计,如何命名CRUD等人的页面？

Question

我正在开发一个网站,其中有很多页面不属于我对RESTful设计的有限理解,这主要是:

Create, Read, Update, Delete, Show, List

这是一个问题:当页面没有整齐地落入CRUD/show/list时,什么是标记动作/路线的好系统？我的一些页面一次有关于多个表的信息.我正在建立一个网站,在登录后为一些客户提供"基地".它没有给他们任何关于他们自己的信息,所以它不应该是,例如,/ customers/show/1.它确实有关于公司的信息,但网站上还有其他页面以不同的方式执行此操作.遇到这些情况后你会怎么做？这个"家庭基地"向客户展示,它主要有关于公司的信息(但不是唯一的).

第二种情况:我在客户和公司之间有一个名为"匹配"的表.这些匹配在网站的不同部分以完全不同的方式访问(不同的布局,不同的CSS表,访问它们的不同类型的用户等等.它们不能全部匹配/显示.标记其他的最佳方式是什么？

非常感谢.=)

Answer 1

我当然不是专家,但如果你重新考虑你的资源并将它们更严格地视为'名词'或至少是数据列表,那么将任何所需的动作放入GET,POST,PUT和DELETE可能更容易.例如,您/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)这本书.

我希望这有点意义并且有所帮助.=)