3

在我正在设计的 Play 应用中，这些是我的一些路线

POST    /visits                     controllers.Visit.create
GET     /visits                     controllers.Visit.visits
GET     /visits/:id                 controllers.Visit.visit(id: Long)
PUT     /visits/:id                 controllers.Visit.update(id: Long)
DELETE  /visits/:id                 controllers.Visit.delete(id: Long)

我也支持浏览器界面。我正在按照我在这里看到的指导进行操作： RESTful on Play！框架

我可以轻松地提供一个 HTML 模板来显示有关特定访问的详细信息或访问列表。但是，“编辑页面”如何完全落入其中，必须预先填充来自特定访问的信息？我可以轻松地执行以下操作：GET /visits/:id/edit controllers.Visit.edit(id: Long)这将返回一个包含访问信息的预填充页面，或者我可以拥有一个静态 HTML 页面，该页面/visits/:id使用 AJAX 调用来填充字段，这将让我避免损坏我的资源驱动 API带有浏览器页面特定的路由。还是有更好的选择？什么是最佳实践，为什么？

4

1 回答 1

2

在 REST 中，仅仅为了执行标准化操作而创建额外的资源是没有意义的。每个了解 HTTP 协议的人都知道您的访问对象应该可以通过带有您要应用的差异的 PATCH 请求进行编辑，或者通过将整个资源替换为新资源的 PUT 请求进行编辑。为什么要使用 POST 创建自定义和非标准编辑操作，您必须记录并向所有人解释它是如何工作的？

从这个意义上说，我会说您最好的选择是拥有一个驱动您的 API 的静态 HTML 页面，在 /visits/:id 上使用 GET 来填充字段，并使用编辑后的内容将 /visits/:id 替换为提交时放置。

但是，请记住，只要您尊重客户端发送的 Accept 标头，在您的 API 中使用特定于浏览器页面的路由并没有错。在我的 API 上，当使用 Accept: text/html 标头发出请求时，我有时会有一些路由返回资源的人类友好表示，因此这是拥有内置管理客户端的简单方法，并且可以轻松地探索 API浏览器。在 REST 中，API 和 WEB 页面之间的唯一区别是第一个返回机器友好格式的表示，第二个返回您希望浏览器在人类友好文档中呈现的表示。他们都应该有链接和/或表格，说明如何编辑资源。

于 2013-11-03T12:24:36.333 回答