GET / entry / new被认为是显示创建新资源的输入表单的最佳实践吗？

Question

考虑一个名为 Entry 的资源，其端点为：

• GET /entries（显示所有条目）
• GET /entries/<x>（显示条目x）
• POST /entries（创建新条目）
• PUT /entries/<x>（更改现有条目x）
• DELETE /entries/<x>（删除现有条目x）

这些我确定。但是如何：

• GET /entries/new（显示用于创建新条目的输入表单）
• GET /entries/<x>/edit（显示现有条目更新的输入表格）

这些模式是否也被视为最佳实践？如果不是，那是什么？

Answer 1

• GET /entries（显示所有条目）
• GET /entries/<x>（显示条目x）
• POST /entries（创建新条目）
• PUT /entries/<x>（更改现有条目x）
• DELETE /entries/<x>（删除现有条目x）

一切正常，正如您所料。

• GET /entries/new（显示用于创建新条目的输入表单）
• GET /entries/<x>/edit（显示现有条目更新的输入表格）

如果你想保持简单，这两个也可以（它们很常见，大玩家和框架使用，尊重RESTful原则并且有点标准）。

源头/样品：

• Microformats wiki - 这里有一些很好的信息，有关于如何解决浏览器方法限制的建议
• Stack Exchange：/questions/ask（而不是/new）来显示创建表单; /questions/id/slugified-title查看; /post/<x>/edit显示修改表单。
• GitHub的问题：/project/issues; /project/issues/new; /project/issues/<x>;他们没有/edit网址，因为所有编辑都是通过JS就地完成的。
• 标准后跟Rails：http://guides.rubyonrails.org/routing.html#crud-verbs-and-actions

长篇故事

为了实现RESTful架构的可伸缩性和松散耦合，有助于根据资源来考虑应用程序。因此，每个URL都应指向不同的资源。所以：

GET /entries/<x>没问题，因为它会返回资源＆＃34;身份<x>的条目＆＃34;。

现在，GET /entries/new也是一种资源，但更多的是＆＃34;实用程序＆＃34;一。只是该地址提供的资源是一个表单（一个解释如何创建条目的文档 - 可能是WADL而不是表单）。

/edit种可能性

GET /entries/<x>/edit，如果你愿意，是我们可以得到的。我们知道，GET返回资源当前状态的表示，而不是（必然）资源。这样，如果资源（当前）可编辑，GET URL将以可编辑的方式返回，否则，它将是只读的（因此不需要/edit资源）。

实现此目标的另一种方法是让GET entries/<x>根据Accept标头返回HTML内容的JSON。这样，如果Accept有text/html，则返回的页面将是包含所有信息的表单（同样，如果资源处于可编辑状态，则表单将是可编辑的。如果不是，然后它将是只读的。

现在我看到这可能不是最佳的，因为您可能不希望每次都显示表单（在GET /entries/<x>上）。如果是这种情况，您将拥有近两种资源：

• GET /entries/<x> - 条目
• GET /entries/<x>/edit - 这个＆＃34;资源＆＃34;将是一个文件，描述客户端如果要编辑条目状态必须进行哪种HTTP请求。在您的情况下，它是一个表单（告诉客户端如何发送或模拟PUT请求），但也可能是一个简短的WADL文件。