RESTful设计，如何在CRUD等外部命名页面？ [英] RESTful design, how to name pages outside CRUD et al?

问题描述

我正在一个网站上有很多页面，这些页面超出了我对RESTful设计的有限理解，本质上是：

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

这是问题：什么是当页面没有整齐地落入CRUD /显示/列表时，用于标记动作/路线的良好系统吗？我的某些页面一次具有有关多个表的信息。我正在建立一个网站，为某些客户登录后提供基地。它不会向他们提供任何有关自己的信息，因此不应提供/ customers / show / 1。它确实包含有关公司的信息，但是网站上的其他页面则对此有所不同。如果遇到这些情况，您该怎么办？向客户显示此家庭，主要包含有关公司的信息（但并非唯一）。

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).

第二种情况：我有一个名为匹配项的表在客户和公司之间。在网站的不同部分（不同的布局，不同的CSS工作表，不同类型的用户访问它们），可以完全不同的方式访问这些匹配项。它们不能全部匹配/显示。标记其他项的最佳方法是什么？

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?

非常感谢。=）

推荐答案

我肯定没有专家，但是如果您重新考虑资源并将其更严格地视为名词或至少是数据列表，则将任何所需的操作放入GET，POST，PUT和DELETE可能会更容易。例如，您有一个 / customers / 资源，大概每个都有一个 / customers / {username} / 资源顾客。也许这给了他们关于自己的信息。您可以将 / homebases / {username} / 或 / customers / {username} / homebase / 作为家庭资源。大概，您将主要通过GET和POST访问该家庭基础资源，如果有任何要更新的地方（由于它是聚合资源，我不希望在家庭基础或仪表板上进行访问）。

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).

对于匹配，您可以使用诸如 / matchings / {customer}，{company} / 之类的东西（是的，允许使用逗号和分号。通常表示这两个部分是顺序相关的，分号表示顺序独立的（尽管没有规则）。从该资源中，您可以让GET读取，显示和列出所需的任何数据（包括作为GET请求的主体传递的可选查询参数），POST进行更新，PUT进行创建以及DELETE进行删除。使用GET中传递的参数，您还可以请求相同数据的不同视图。当然，您可以拥有该匹配项的子资源，例如 / matchings / {customer}，{company} / invoices / {invoice＃} / 。

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#}/.

顺便说一句，我喜欢这本书 RESTful Web Services（2007 O'Reilly）。

I liked the book "RESTful Web Services" (2007 O'Reilly), by the way.

我希望这能使读者有所收获感和帮助。 =）

I hope that makes some sense and is helpful. =)

这篇关于RESTful设计，如何在CRUD等外部命名页面？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！