我有一个名为“事实”的资源集合的 URI，以及该集合中每个“事实”资源的 URI。
我相信，创建新“事实”的表单应该使用 GET 来请求，但我无法确定应该将其设置为哪个 URI。
对集合 URI 的 GET 应返回“事实”资源 URI 的列表。每个“事实”URI 都应返回其内容作为对 GET 的响应。当然，实际的“事实”创建将是 POST（或 PUT，具体取决于情况）。
我看到了一些选择，但似乎没有一个令人满意：
- 添加“事实”URI 将引用的“事实形式”URI。对此 URI 的 GET 给出 HTML 表单。仅仅为了描述资源而使用另一个资源似乎是错误的。
- 对“facts”URI 进行 POST 而不在标头中包含任何表单数据将返回该表单。然后，在用户填写表单后，它将使用表单数据进行 POST，并创建新的“事实”资源。这似乎是一个更糟糕的方法。
- 不要通过网络发送表单，而是将其作为 API 的一部分。这看起来是 RESTful，因为 REST API 应该描述媒体类型，并且可以根据“事实”类型的描述创建表单。这实施起来很奇怪。也许 REST 服务与常规网站是分开的，因此实际的 HTML 表单请求位于除 REST API 之外的某个 URI。
- 将 HTML 表单作为“事实”URI 响应的一部分包含在内。
澄清一下，我试图遵循 Roy Fielding 指定的真正的 REST 架构，而不是冒充 REST 的半生不熟的 RPC。
编辑：我开始认为#3 是有道理的。
edit2：我认为解决方案是以 CRUD 方式进行常规非 REST HTML 导航，然后前端根据需要进行 AJAX REST 调用（或者后端对其 REST API 进行内部调用）。
我需要正确执行此服务的 REST 部分的原因是我希望允许其他非 HTML 客户端稍后与其交互。
在我看来，唯一完全 RESTful 的答案是 1 和 3。
在我看来，资源的描述本身就是一种资源。问题是您是否希望通过应用程序的 API 访问此资源，或者是否希望使其成为 API 本身的一部分。
对于 1，RESTful 似乎使 URI 看起来像这样：
GET /facts -> 所有事实
GET /facts/1 -> 返回事实 1 （显然 id 可能是一个单词或其他东西）
GET /facts/create -> 返回适合创建事实的表单
POST /facts -> 添加一个事实
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
