我对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>...但是这看起来很丑陋给我.
思考？
1)拥有两个不同的资源是完全有效的,一个用于查看,另一个用于编辑一些域概念.请注意,因为它们是REST的两个不同的URI,所以它们是两种不同的资源.人们经常将资源与域对象混为一谈.这就是为什么他们最终只被卡住了CRUD.
2)不要太挂在资源的名称上.重要的是你意识到URI指向的是"事物","资源".如果这对你来说更明显,editable而不是edit那么使用它.在您的URL中使用动词不会使您的应用程序出错,它只会使人类开发人员的可读性降低一些.使用URL中的动词来尝试重新定义HTTP方法的语义,现在这违反了统一接口约束.