3

我正在开发针对远程服务器运行的 iOS 应用程序，背后有另一个开发人员。我们正在编写的项目和 API 草案处于初始阶段。

我们面临的问题是我们对现有的 HTTP/REST 规范描述的常规状态代码数量不满意：在某些情况下，我们不确定要选择什么代码。

提供最少上下文的示例：

  1. 服务器端验证错误。外汇。客户端验证没问题，但服务器 API 最近略有更改，因此服务器应该返回一些内容，表明这正是验证问题。

  2. 尝试注册已存在的用户。SO主题没有提供任何精确的观点。

  3. 用户已注册，并在未完成密码确认过程的情况下尝试登录。

我们在这里看到两种明显的方法：

  1. 在找不到适当的常规状态代码的情况下使用 fx 400 错误。这将导致我们从 JSON 响应中解析错误文本消息。显然，这种方法会在客户端代码中引入多余的复杂性。

  2. 创建我们自己的子代码系统并在我们的代码中依赖它。这涉及太多人为的惯例，这将导致我们变得过于固执和武断。

感觉这种情况的数量会增加，我们正在考虑在我们的服务器应该提供的 JSON 响应中引入自定义子代码（即选择第二种方法）。

我在这里问的是：

对于这些情况，推荐的方法、策略，甚至是胶水或技巧是什么？

不严格遵循状态代码的 REST/HTTP 约定有什么好处？

谢谢！

4

3 回答 3

4

对于验证问题，我使用 422 Unprocessable Entity (WebDAV; RFC 4918) 请求格式正确，但由于语义错误而无法遵循。这是因为请求失败不是因为语法错误，而是因为语义。

然后，为了进行交流，您只需要确定错误格式，因此对于情况 1，如果有必填字段，您可能会返回 422 和以下内容。

{
  "field": ["required"]
}

我会将第二个视为验证问题，因为它实际上是用户名的验证问题，因此 422 如下所示。

{
  "username": ["conflict"]
}

第三，我将其视为 403 Forbidden，因为传递授权标头将无济于事，并且将被禁止，直到他们执行除传递凭据之外的其他操作。

您可以执行类似oauth2的操作并返回一个人类可读的描述，一个人们可以对其进行编码的常量，进一步澄清错误和一个 uri 以获取更多信息。

{
  "error": "unfinished_registration",
  "error_description": "Must finish the user registration process", 
  "error_uri": "http://yourdocumentation.com"
}

注意：您会发现人们不同意什么 http 代码映射到什么情况以及是否应该使用 422，因为它是 WebDAV 扩展的一部分，这很好，您可以做的最重要的事情是记录代码的含义和含义与他们的意思一致而不是完美。

于 2012-09-20T15:28:49.100 回答
3

HTTP 中没有“子代码”之类的东西（Microsoft IIS 显然违反了规范，应该被鞭打）。

如果有合适的状态码，使用它；不要说“这个状态代码在我的应用程序中意味着那个”，因为那失去了通用状态代码的价值；您不妨设计自己的协议。

之后，如果您需要细化状态码的语义，请使用标题和/或正文。

于 2012-09-21T00:49:08.373 回答
2

对于您描述的用例，您可以使用以下错误代码：

1) 400 错误请求

由于语法错误，服务器无法理解该请求。客户端不应该在没有修改的情况下重复请求。

2）409冲突

由于与资源的当前状态冲突，无法完成请求。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。响应正文应该包含足够的

供用户识别冲突来源的信息。理想情况下，响应实体将包含足够的信息供用户或用户代理解决问题；但是，这可能是不可能的，也不是必需的。

响应 PUT 请求时最有可能发生冲突。例如，如果正在使用版本控制并且被 PUT 的实体包含对资源的更改，这些更改与早期（第三方）请求所做的更改相冲突，则服务器可能会使用 409 响应来指示它无法完成请求. 在这种情况下，响应实体可能会以响应 Content-Type 定义的格式包含两个版本之间差异的列表。

3) 401 未授权

该请求需要用户身份验证。响应必须包含一个 WWW-Authenticate 头字段（第 14.47 节），其中包含适用于所请求资源的质询。客户端可以使用合适的授权头域重复请求（第 14.8 节）。如果请求已包含授权凭证，则 401 响应表示已拒绝对这些凭证的授权。如果 401 响应包含与先前响应相同的质询，并且用户代理已经尝试了至少一次身份验证，则应该向用户呈现响应中给出的实体，因为该实体可能包含相关的诊断信息。HTTP 访问身份验证在“HTTP 身份验证：基本和摘要式访问身份验证”[43] 中进行了说明。

对于您拥有的任何其他用例，它会有所不同。如果真的没有编码特定错误的标准方法，我可能会选择 2 号。

于 2012-09-20T14:17:59.663 回答