javascript - WebAPI 和 401 与 200

Question

我正在构建一个 WebAPI 作为一个学习项目并尝试使用最佳实践。我的第一次尝试是身份验证 API，它采用身份验证对象 (JSON):

{
   username: myusername, 
   password: mypassword
}

它在/api/authenticate 上调用我的 API 作为 POST，传递对象。

在我的 .Net 代码中，我做了一些检查，如果用户名/密码通过，我创建一个 jwt token ，并返回它和 Angular 色。我的 API 返回 200，正文中带有 token (Chrome 开发人员工具中的响应显示“ey.....”，这是我的 jwt)。

如果我收到无效的用户名/密码，我将返回 401。

我不确定这是对的。我是否应该返回一个 200 - 和 body 中的其他一些有效载荷？ (不确定是什么)，然后我的登录成功是否应该返回JSON，例如:

{
  success: true,
  error: null
  token: "ey.....",
}

登录失败返回:

{
  success: false,
  error: null
  token: null,
}

然后是一个错误:

{
  success: false,
  error: 500
  token: null,
}

然后客户端代码使用它来决定做什么？我正在努力研究这里的最佳实践，以了解如何在 WebAPI 中处理此问题。

Answer 1

我不认为这里真的存在“最佳实践”。一些 API 返回一个错误对象，就像您对 JSON 所做的那样。那完全没问题。其他 API 返回 HTTP 错误(401、500 等)。其他 API 两者都返回。每种方法都有利有弊，因此请选择您喜欢或最适合您需求的方法。

如果您使用第一种方法，请不要将自己局限于返回 HTTP 代码。相反，返回代码可以为您和 API 的使用者提供更具体的错误引用。例如，代码 401 没有告诉我身份验证失败的原因。可能这对安全性没问题，但我在这里仅将其用作示例，因此您可以为不正确的凭据返回代码 1001，为锁定的帐户返回 1002，为待批准的帐户返回 1003，等等...

第一种方法的优点:API 使用者可以使用简单的 if...else 或 switch 逻辑处理同一代码中的所有内容。它也更容易测试。缺点:还是需要用try...catch，因为对API的请求还是有可能失败，所以消费者代码会有上面的逻辑加上try...catch 逻辑。

第二种方法的优点:更符合我们平时做事的方式。使用try...catch 来处理所有的错误，里面的代码只会针对成功的路径。缺点:测试起来有点困难，而且您会遇到 HTTP 错误代码。

第三种方法是两者的结合。在某些情况下，这可能有点矫枉过正，增加了一些不必要的复杂性和重复，但在其他情况下，它可以结合两个世界的好处。