REST风格的设计：应该重新命名的资源永远封锁旧的URI吗？

我想了解RESTful Web Services第274部分HTTP PUT。针对不存在的资源颁发PUT将创建该资源。如果PUT导致现有资源移动，则返回HTTP 301 (Moved Permanently)与新位置。请求旧URI返回HTTP 301,404或410.REST风格的设计：应该重新命名的资源永远封锁旧的URI吗？

我的问题是关于返回HTTP 301。这似乎意味着资源永远保留旧的URI的所有权。

考虑：/companies/{companyName}/departments/{departmentName}

我看到使用HTTP 301以下好处：

并发：如果一个用户重命名一个公司，而另一个是在导航到一个部门的过程中，后者尽管他们没有做错任何事情，但会获得HTTP 404。 HTTP 301允许我们将第二个用户无缝地重定向到新的URI。
书签：人类和计算机都需要书写URI以进行长期存储。人类在讨论论坛上张贴链接。计算机使用URI来缓存目的和用户偏好。

我看到HTTP 301以下问题：

块长期演进资源：在其生命时间，部门A更名为B，C和D。几年后，有人想创建部门A，并且由D阻止这样做。公平地说，我想不出任何会发生这种情况的实际例子，所以这可能不是问题。
API版本限制其使用：随着新API版本的发布和旧版本的移除，甚至根资源也会随着时间而变化。如果客户端无法像旧版一样访问新资源，那么返回HTTP 301有什么意义？

什么是适当的行动方案？ URL层次结构应该以不同的方式建模吗？行为/反应应该不同吗？

来源

2012-11-26 Gili

“310”究竟是什么？我见过的唯一参考文献是'太多重定向' – Aesthete

@Aesthete，看起来像书中的一个错字。作者的意思是HTTP 301.我已经纠正了这个问题。 – Gili

回答我的问题：

我想不出哪里保持HTTP 301永远会造成问题的任何实际的例子。
链接并不意味着在API版本中生存。一个版本的资源不应该引用另一个版本的资源（即使使用HTTP 301）。如果由于API更改而导致资源的URI发生更改，则旧的API应该继续使用旧的URI。

UPDATE：根据Willy Tarreau幂等只需要为很短的时间周期重定向该应用程序。一旦客户端完成重试请求，重定向不再需要（至少不是幂等）。您可能希望长时间保持重定向，以支持诸如永久链接之类的功能，但规范中没有任何内容会强制您执行此操作。

来源

2012-12-06 21:46:57 Gili

我会返回一个简单的404。这表示没有与请求的uri匹配，并且从documentation指定：

没有指示条件是临时的还是永久的。

通过这种方式，创建新的资源以取代过去存在的资源是完全有效的。

否则，如果您要通过重命名移动资源，您始终可以返回302，指定资源驻留在不同的位置。您可以返回此状态直至生成替换。用户必须继续使用这些头，以确保资源仍然是搬迁：

由于重定向可能偶尔被改变，客户应继续使用Request-URI为将来的请求。

来源

2012-11-26 04:47:34 Aesthete

如果PUT导致现有资源移动，则HTTP 301与新位置一起返回。

从技术上讲，您不能在移动资源在HTTP中。如果你正在操纵的资源作为客户端，你在做什么是：

GET /oldurl 
PUT /newurl 
DELETE /oldurl

，服务器将不知道新的URL是在旧的URL资源的新位置，并没有URL的概念通过使用通用HTTP方法的客户端可以建立的重定向持久性。如果该服务提供了一个允许您移动项目的API（例如通过传递某些参数），并且基本上在幕后执行上述操作，但也可以在此过程中创建重定向，则服务是否需要重定向可以用新的PUT操作覆盖，以及使用什么样的重定向。

这是我的理解，当一个职位标题被重命名，我们应该跟踪旧名称并返回HTTP 301时，客户端引用旧地址。

这与REST无关，是Cool URIs don't change的体现。在RESTful服务中，通过从服务入口点可访问的资源或资源序列链接到新的URL就足够了。

例如一个HTML网站是一个REST实现的规范例子

服务入口点= /博客
/博客链接到/博客/存档
/博客/存档链接/博客/新标题后

由于博客服务被设计为由使用网络浏览器的人类消费，因此期望他们可能希望为稍后重新访问的URL添加书签。这是重定向的目的。

机器对机器的API有做类似的事情：

服务入口点=/
/链接到/公司提供的相对的 “http：//为MyService/RELS /公司”
/公司链接到/公司/新公司名称与rel的“项目”

没有必要提及旧公司名称，因为机器不需要为位置添加书签，而是开始导航每次从入门点开始。

来源

2012-11-26 12:03:05

我的问题“机器预计不会书签的位置”。客户端缓存恰好是：书签位置。书签位置的另一个例子是“客户端偏好”，如“正在监控的RSS源”或“Facebook好友”。重命名博客和用户帐户不应导致RSS提要和Facebook好友丢失。 – Gili

好点。当我写这些时，我并没有考虑缓存。我一定把我的大脑关掉了。 –

REST风格的设计：应该重新命名的资源永远封锁旧的URI吗？

回答

相关问题