Question

好。我想知道在这种情况下可能的HTTP状态（响应）代码是什么。

可以说，POST /Student/创建了学生资源。假设有多个表要更新。 Student资源已创建。

通常，在创建资源时，应立即在200 Successful的响应中返回资源。

但是，假设资源已创建，但是当您尝试提取资源（来自数据库的查询）失败时。我们应该返回什么状态代码？

   `201 Created`? (No resource)
   '200 Successful`? but without the resource. 
   `500 Internal Server Error`?

还有别的吗？

我认为这是一种常见的情况。

修改

我想澄清一下。首先，它的所有ONE POST调用都是为了创建一个资源。响应应为200，资源对象为JSON。但是在检索资源期间出现了 only 错误（资源已成功创建）。

无法从数据库获取资源的原因可能是间歇性的，可能与服务器/网络相关，可以在以后识别和修复。但是资源肯定是成功创建的。

Answer 1

假设资源已创建，但是当您尝试提取资源（来自数据库的查询）失败时

然后资源已创建不。只有出现。这肯定是服务器端错误，因此是5xx代码。

除非有用户提供的参数导致失败，否则它将是4xx代码。

更新：或者如果我误解了，你的意思是创建没问题并且返回了资源ID，那么后来的有效GET后来找不到该资源查询，那么，在这种情况下，您在服务器代码中有一些损坏，并且应该之前发出5xx错误。解决方法可能是创建资源，从资源创建代码发出查询，如果失败则返回200或执行清理，重试或5xx返回。但真正应该做的是调查导致资源消失的任何内容或者只看起来已经被创建（例如并发问题，错误的事务管理，缓存......）。

复杂情景

REST服务请求创建资源，服务器接受请求。服务器本身将请求路由到后端，比方说一个数据库，它返回（到服务器）“OK”和资源ID。然后是服务器，以防万一，检查，并询问资源ID。数据库响应，“没有这样的资源”。

在这种情况下，服务器无法良心地向其客户端返回200代码和资源ID，而不是在有充分理由怀疑客户端在尝试使用该资源ID时会遇到麻烦时。之后的错误可能要难得多：客户可能已发送电子邮件或采取涉及该ID的复杂操作。

因此，无论是返回500，还是服务器都可以尝试修复这种情况，在适当和可能的情况下应用以下一项或多项：

等待一小段时间（客户端仍在等待！）并检查资源再现
尝试刷新缓存或以其他方式刺激数据库咳嗽资源
使资源无效
删除资源（即使显然它不存在）
记录错误并将详细信息发送给管理员
重复资源创建一定次数（不是太大，或者我们可能会将一个短暂的问题变成一种自我否定的服务）直到它起作用

如果情况在合理且可容忍的（由客户端）时间内得到修复，则可以使用代码200返回工作资源。

当然，上述所有实际发生的原因都必须进行调查和纠正。可能一些“孤儿”资源可能不得不定期从数据库中清除（总是一个尴尬的命题）。

Answer 2

您可以使用201 Created作为it doesn't mandate to return the created entity。如果客户端尝试检索它，它将获得500 Server Error。

如果您想让客户知道可能的服务器shenanigan，您可以it is non-committal返回202 Accepted。

无论你做什么，我建议你使这个资源具有幂等性，因为它似乎有复杂的失败模式，客户可能会重新尝试创建。

Answer 3

当你陈述时，你错了：

响应应为200，资源对象为JSON。

响应应为 201 而不是200，并且应设置Location:标头。无需在响应中包含资源表示。如果你想包含它，你的代码看起来像这样：

mysql_query('INSERT ...'); // succeeds
$id = mysql_insert_id(); // succeeds
$result = mysql_query('SELECT ...'); // times out

然后返回201没有身体。如果需要，客户端可以再次尝试获取创建的资源。

REST响应代码，用于成功添加但无法返回创建的对象

3 个答案:

复杂情景