在 REST API 中，什么时候我应该使用信封？如果我在一个地方使用它，我应该一直使用它吗？

我正在致力于构建 RESTful Web 服务。我已经尽可能地阅读了每种机制使用 HTTP 的原理，并且大多数时候，比如在获取资源时，它都工作得很好。

但是，当我需要发布某种新条目时，为了清晰和稳健，无论客户端可能做什么，我都想提供新条目可能失败的特定验证错误。此外，还存在一些特定错误，例如，用于创建新用户的数据完全有效，但可能会使用昵称或电子邮件地址。简单返回409 Conflict没有足够详细地说明哪个昵称或电子邮件地址被盗用了。

因此，解决这个问题并不是火箭科学：记录一堆特定的错误代码并返回一个有错误的对象：

{ errors: [4, 8, 42] }

这意味着，在请求不成功的情况下，我不会像 REST 哲学所期望的那样返回资源或其密钥。同样，当我返回许多资源时，我必须以某种方式将它们放入数组中。

所以我的问题是：如果我标准化一个信封以用于每个请求，那么我是否仍然可以提供行为良好的 RESTful Web 服务，例如，总是有一个像这样的对象{ errors, isSuccessful, content }?

我之前曾使用它构建过 RPC 风格的 Web 服务，但我不想制作“几乎 REST”的东西。如果休息有什么意义的话，我希望表现得尽可能好。

如果答案是“绝对不”（我认为可能是这样），我想听听它是否至少正确地解决了验证问题，以及解决此类问题的一个很好的参考可能是什么，因为大多数指南我'我们发现只详细介绍了简单的情况。

是的，信封是个好主意！总是有一些额外的信息需要从某些端点发送。例如分页、errorMessages、debugMessages。 Facebook 的做法示例：

Response from get friends request

{
  "data": [
    {
      "id": "68370", 
      "name": "Magnus"
    }, 
    {
      "id": "726497", 
      "name": "Leon"
    }, 
    {
      "id": "57034", 
      "name": "Gonçalo"
    }
  ], 
  "paging": {
    "next": "https://graph.facebook.com/v2.1/723783051/friends?fields=id,name&limit=5000&offset=5000&__after_id=enc_AeyGEGXHV9pJmWq2OQeWtQ2ImrJmkezZrs6z1WXXdz14Rhr2nstGCSLs0e5ErhDbJyQ"
  }, 
  "summary": {
    "total_count": 200
  }
}

在这里，我们使用下一个链接进行分页，以请求获取下一个用户块，以及可以获取的朋友总数的摘要。然而，他们并不总是发送这个信封，有时数据可以直接进入正文的根部。始终以相同的方式发送数据使客户端更容易解析数据，因为它们可以对所有端点执行相同的操作。客户端如何处理信封响应的一个小示例：

public class Response<T> {
  public T data;
  public Paging paging;
  public Summary summary;
}

public class Paging {
  public String next;
}

public class Summary {
  public int totalCount;
}

public class WebRequest {
  public Response<List<User>> getFriends() {
    String json = FacebookApi.getFriends();
    Response<List<User>> response = Parser.parse(json);
    return response;
  }
}

然后，只需将 List 更改为端点返回的数据，即可将该 Response 对象用于所有端点。