28

我在一个名为 Apigility 的基于 ZF2（Zend 框架 2）的框架中编写了一个 API。

我的服务可以查询 3rd 方 API。偶尔，我会收到一条 500 错误消息。可能是由于令牌过期或其他原因。

我的 API 应该如何响应我的客户？

起初我以为我应该返回 500，但实际上这似乎是错误的。我不想返回一个错误，表明我已经崩溃了。它是第 3 方，有 500 个。

更新：以下是我从第三方看到的。

我想我喜欢503 Service unavailable.. 的想法，带有一条错误消息，提示用户知道出了什么问题，以及如何解决它。

更新显示第 3 方的响应：

Error performing request to OAuth Provider. 
HTTP/1.1 500 Internal Server Error
Server: nginx/1.1.19
Date: Fri, 22 Aug 2014 20:24:40 GMT
Content-Type: text/html
Content-Length: 20
Connection: close
X-Powered-By: PHP/5.3.10-1ubuntu3.1
Set-Cookie: lang_select_language=en; Expires=Sun, 21-Aug-2016 20:24:42 GMT; Path=/
X-WI-SRV: FR-EQX-WEB-03
Vary: Accept-Encoding
Content-Encoding: gzip

想法？

/**
 * Status titles for common problems
 *
 * @var array
 */
protected $problemStatusTitles = array(
    // CLIENT ERROR
    400 => 'Bad Request',
    401 => 'Unauthorized',
    402 => 'Payment Required',
    403 => 'Forbidden',
    404 => 'Not Found',
    405 => 'Method Not Allowed',
    406 => 'Not Acceptable',
    407 => 'Proxy Authentication Required',
    408 => 'Request Time-out',
    409 => 'Conflict',
    410 => 'Gone',
    411 => 'Length Required',
    412 => 'Precondition Failed',
    413 => 'Request Entity Too Large',
    414 => 'Request-URI Too Large',
    415 => 'Unsupported Media Type',
    416 => 'Requested range not satisfiable',
    417 => 'Expectation Failed',
    418 => 'I\'m a teapot',
    422 => 'Unprocessable Entity',
    423 => 'Locked',
    424 => 'Failed Dependency',
    425 => 'Unordered Collection',
    426 => 'Upgrade Required',
    428 => 'Precondition Required',
    429 => 'Too Many Requests',
    431 => 'Request Header Fields Too Large',
    // SERVER ERROR
    500 => 'Internal Server Error',
    501 => 'Not Implemented',
    502 => 'Bad Gateway',
    503 => 'Service Unavailable',
    504 => 'Gateway Time-out',
    505 => 'HTTP Version not supported',
    506 => 'Variant Also Negotiates',
    507 => 'Insufficient Storage',
    508 => 'Loop Detected',
    511 => 'Network Authentication Required',
);
4

3 回答 3

26

好吧，我认为这取决于您，您将使用哪个错误代码。但是，如果您的 API 的实际功能依赖于 3rd 方 API，我会考虑使用 HTTP 代码503 Service Unavailable，因为无论 3rd 方 API 返回什么 HTTP 代码，在 3rd 方 API 无法工作之前，您的服务都将不可用。我还将在响应有效负载中包含一些详细信息（错误消息）。

或者您可以返回 HTTP 代码200 OK并将自定义错误代码和消息作为响应负载发送，当然，因为对您的 API 的 HTTP 请求实际上是成功的。但我更愿意使用 HTTP 代码来指示 API 端点的状态。

只有在您的 API 充当代理而没有任何附加功能的情况下，我才会将来自第 3 方 API 的 HTTP 代码镜像给用户。

于 2014-08-22T20:28:52.600 回答
4

当客户端调用您的 API 时，它是否直接或间接指定它希望您的 API 与 3rd 方服务进行通信？

  • 否 - 那么对于客户端它将是 500，因为从客户端的角度来看它仍然是内部服务器错误。除非您的 API 可以解释来自 3rd 方服务的错误消息并派生更具体的错误代码。

  • 是的 - 那么 503 似乎是最合适的。错误消息可能会指定哪些服务不可用。

于 2014-08-22T20:33:41.283 回答
3

我认为这里的第一步是确定范围。4xx 意味着用户有机会修复请求，这里不是这种情况。2xx 听起来也不正确，因为请求不成功。这给我们留下了 5xx 范围内的东西。

在 5xx 范围内，有两个选项对我来说很合适。一个简单的 500 就可以了：“存在未指定的服务器错误”。503 听起来也不错，意思是“我们现在无法实现这一点，但稍后可以实现（可选地在标题中指定重试跨度）。

于 2020-06-19T00:10:19.870 回答