url - 如何以 REST 风格获取只读资源与可编辑资源？

Question

我对 REST 原则相当熟悉，并且阅读了相关论文、维基百科条目、大量博客文章和 StackOverflow 问题，但仍然没有找到常见情况的直接答案:

我需要请求要显示的资源。根据资源的状态，我需要呈现只读或可编辑的表示形式。在这两种情况下，我都需要获取资源。如何构造 URL 来获取只读或可编辑版本？

如果我的用户点击 GET /resource/<id> 的链接，这足以向我表明他/她需要只读表示。但如果我需要提供可编辑的表单，该 URL 是什么样的？ GET /resource/<id>/edit很明显，但它在 URL 中包含一个动词。将其更改为 GET /resource/<id>/editable解决了这个问题，但只是表面上看起来很肤浅。这就是全部内容了吗——将动词改为形容词？

如果我使用 POST 来检索可编辑版本，那么如何区分最初检索它的 POST 和保存它的 POST？我使用 POST 的(弱)借口是检索可编辑版本会导致服务器状态发生变化:锁定资源。但这仅适用于我的要求是实现这样的锁，但情况并非总是如此。 PUT 由于同样的原因而失败，而且我正在运行的 Web 服务器上默认情况下未启用 PUT，因此有实际原因不使用它(和 DELETE)。

请注意，即使在可编辑状态下，我也还没有进行任何更改；想必当我再次将资源提交到 Web 服务器时，我会 POST 它。但为了获得稍后可以发布的内容，服务器必须首先提供特定的表示。

我想另一种方法是在集合级别拥有单独的资源: GET /read-only/resource/<id>和GET /editable/resource/<id>或GET /resource/read-only/<id>和GET /resource/editable/<id> ...但这对我来说看起来很丑。

想法？

Answer 1

1) 拥有两种不同的资源是完全有效的，一种用于查看，一种用于编辑某些域概念。请注意，因为从 REST 的角度来看它们是两个不同的 URI，所以它们是两个不同的资源。人们常常将资源与域对象混为一谈。这就是为什么他们最终只能做 CRUD。

2) 不要太在意资源的名称。重要的是你要意识到 URI 指向的是“事物”、“资源”。如果使用 editable 而不是 edit 对您来说更明显，那么就使用它。在 URL 中包含动词并不会让您的应用程序出错，它只会降低人类开发人员的可读性。在 URL 中使用动词来尝试重新定义 HTTP 方法的语义，这违反了统一接口(interface)约束。