RESTful设计，如何命名CRUD等之外的页面？
我正在开发一个网站，该网站有相当多的页面超出了我对 RESTful 设计的有限理解，这本质上是：
Create, Read, Update, Delete, Show, List
问题是：当页面没有整齐地落入其中时，什么是用于标记操作/路线的良好系统？ CRUD/显示/列表？我的一些页面同时包含有关多个表的信息。我正在建立一个网站，为一些客户登录后提供一个“大本营”。它不会向他们提供有关其自身的任何信息，因此不应该是/customers/show/1。它确实包含有关公司的信息，但网站上的其他页面的做法有所不同。当你遇到这些情况时你会怎么做？这个“基地”向客户展示，主要包含有关公司的信息（但并非唯一）。
第二种情况：我在客户和公司之间有一个名为“匹配”的表。这些匹配在网站的不同部分以完全不同的方式访问（不同的布局、不同的 CSS 表、访问它们的不同类型的用户等。它们不可能都是匹配/显示。标记其他匹配的最佳方法是什么？
非常感谢=）。
I'm working on a site that has quite a few pages that fall outside my limited understanding of RESTful design, which is essentially:
Create, Read, Update, Delete, Show, List
Here's the question: what is a good system for labeling actions/routes when a page doesn't neatly fall into CRUD/show/list? Some of my pages have info about multiple tables at once. I am building a site that gives some customers a 'home base' after they log on. It does NOT give them any information about themselves so it shouldn't be, for example, /customers/show/1. It does have information about companies, but there are other pages on the site that do that differently. What do you do when you have these situations? This 'home-base' is shown to customers and it mainly has info about companies (but not uniquely so).
Second case: I have a table called 'Matchings' in between customers and companies. These matchings are accessed in completely different ways on different parts of the site (different layouts, different CSS sheets, different types of users accessing them, etc. They can't ALL be matchings/show. What's the best way to label the others?
Thanks very much. =)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我当然不是专家，但如果您重新思考您的资源，并将它们更严格地视为“名词”或至少是数据列表，那么将任何所需的操作放入 GET、POST、PUT 和 DELETE 中可能会更容易。例如，您有一个
/customers/资源，可以推测每个客户都有一个/customers/{username}/资源。也许这给了他们关于自己的信息。您可以将/homebases/{username}/或/customers/{username}/homebase/作为您的总部资源。据推测，您主要通过 GET 访问该 homebase 资源，如果有任何需要更新的内容，则通过 POST 访问该 homebase 资源（我不希望在 homebase 或仪表板上出现这种情况，因为它是聚合资源）。对于“匹配”，您可以使用类似
/matchings/{customer},{company}/（是的，允许使用逗号和分号。逗号通常表示两个部分依赖于顺序，分号表示顺序-独立，尽管没有任何规则）。从该资源中，您可以使用 GET 来读取、显示和列出所需的任何数据（包括作为 GET 请求正文传递的可选查询参数）、使用 POST 来更新、使用 PUT 来创建以及使用 DELETE 来删除。使用 GET 中传递的参数，您还可以请求相同数据的不同视图。当然，您可以拥有该匹配的子资源，例如/matchings/{customer},{company}/invoices/{invoice#}/。顺便说一句，我喜欢“RESTful Web Services”（2007 O'Reilly）这本书。
我希望这有一定道理并且有帮助。 =)
I'm certainly no expert, but if you rethink your resources and think of them more strictly as 'nouns' or at least lists of data, it might be easier to fit any desired action into GET, POST, PUT, and DELETE. For example, you have a
/customers/resource could presumable have a/customers/{username}/resource for each customer. Maybe that gives them information about themselves. You could have/homebases/{username}/or/customers/{username}/homebase/as your homebase resources. Presumably, you'd access that homebase resource mainly through GET, and POST if there's anything there to update (which I wouldn't expect on a home-base or dashboard since it's an aggregate resource).For 'matchings' you could use something like
/matchings/{customer},{company}/(yes, commas and semicolons are allowed. Commas usually mean the two parts are order-dependent and semicolon means order-independent, though there's no rules about it). From that resource, you can have GET to read, show, and list whatever data you need (including optional query parameters passed as the body of the GET request), POST to update, PUT to create, and DELETE to delete. Using the parameters passed in GET, you could also request different views of the same data. Of course, you can have sub-resources of that matching like/matchings/{customer},{company}/invoices/{invoice#}/.I liked the book "RESTful Web Services" (2007 O'Reilly), by the way.
I hope that makes some sense and is helpful. =)
我认为聚合和综合观点是一个严重的问题。我必须处理主页问题，这与我所知道的 RESTful 的一切背道而驰。
我的解决方案是将主页或仪表板本身视为一种资源，但这种资源只有 GET 操作才有意义。像往常一样，主页上的 POST/PUT/DELETE 被定向到特定资源。
相比之下，匹配问题似乎更容易解决。从您的描述来看，这似乎是客户和公司之间的简单映射，您可以根据查询字符串参数对其进行参数化。
Aggregate and composite views are a serious problem, I think. I had to deal with the
homepageproblem that went against everything RESTful I knew.My solution was to consider the homepage or dashboard as a resource in itself, but a resource where only GET operations made sense. POST/PUT/DELETE from the homepage were directed to the specific resources as usual.
Matchings, in contrast, seems an easier problem to tame. It seems like a simple mapping between Customers and Companies from your description, and you could parametrize it based on querystring parameters.
我认为您所说的 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 警察不会来逮捕你:-)
By RESTful design, I assume you mean RESTful web services, since a REST-based architecture has a much broader sense than that.
The main thing to consider is that REST-based architectures rely on the HTTP protocol, in virtually all cases. Since HTTP specifies a set of methods, sometimes these methods are used to create the so called RESTful web services.
But the RESTful web services don't follow any concrete standard (unlike SOAP). It is common to use:
Create, Read, Update and Delete (CRUD) are the basic functions of any persistent storage.
It is easy to see that in common RESTful web services, each HTTP method is being used to match one of the basic functions, but the point is: it doesn't have to be this way.
There are other things to consider, URL mapping is one of them (as this is the concern of your question), security is another. POST requests send the content of the request in the HTTP body (which can be encrypted), but GET requests send it in the URL, visible for everyone to see.
If one wants to develop a secure (encrypted) RESTful web service, one could make all requests HTTPS POST, and then specify within the request, which of the CRUD operations one wants to perform, and on what resources.
One could also expand the CRUD concept to a wider range, in fact, in almost every application, one has to.
Remember CRUD are just the four basic operations in which all other actions can build upon. There's no standard you have to follow, you can specify your own protocol, according to what makes sense in your context, and keeping all the relevant considerations in mind (security, URLs, etc.)
Specifically regarding your question, you can have your own actions, like show_by_x, show_by_y, etc. The REST police is not coming to arrest you :-)
REST 和 ORM 是两个不同的东西，因此，即使您有一个名为 User 的模型，您也需要拥有用户资源。资源应该在 Rails 控制器级别进行管理
将资源视为模块/部分
例如：您可能希望用户在登录后登陆仪表板页面（假设您有两类用户：管理员和普通用户），这样您就可以有两个资源，即
admin_dashboard
uer_dashboard
和两者都可能只读取操作
第二种情况：
如果可能的话，考虑使用上面的示例（根据不同的用户级别使用不同的资源），
我不是 REST 大师，但希望这会有所帮助：D
欢呼，
萨梅拉
REST and ORM is 2 different things, because of that even though you have a model called User , you done necessary to have a users resource. Resources should be managed in the rails controller level
Think resources as modules/sections
Ex: you might want your users to land on a dashboard page after they log in (and say you have two categories of users Administrators and normal users), so you can have two resources namly
admin_dashboard
uer_dashboard
and both might only have read action
Second case :
consider having something like above example (different resources according to different user levels) if possible
I'm not a REST guru, but hope this helps :D
cheers,
sameera