对于后面的内容，除了包括HAL、JSend和JSON API的公认答案之外，我还将添加一些其他值得研究的规范：

JSON-LD，它是W3C推荐标准，规定了如何以JSON构建可互操作的Web服务Ion Hypermedia Type for REST，自称是“一种简单直观的基于JSON的REST超媒体类型”

JSON的关键在于它是完全动态和灵活的。你可以随心所欲地使用它，因为它只是一组序列化的JavaScript对象和数组，植根于一个节点。

rootnode的类型取决于您，它包含的内容取决于您、是否随响应一起发送元数据取决于您以及是否将mime类型设置为application/json或将其保留为text/plain取决于您（只要您知道如何处理边缘情况）。

构建您喜欢的轻量级模式。就我个人而言，我发现分析跟踪、mp3/ogg服务、图片库服务、在线游戏的短信和网络包、博客帖子和博客评论在发送内容、接收内容以及如何消费方面都有着非常不同的要求。

所以，在完成所有这些工作时，我最不想做的就是让每一个都符合相同的样板标准，该标准基于XML2.0或类似的标准。

也就是说，使用对你有意义且经过深思熟虑的模式有很多值得说的地方。只需阅读一些API响应，注意你喜欢的，批评你不喜欢的，写下这些批评，并理解它们为什么会让你感到不舒服，然后思考如何将你学到的东西应用到你需要的东西上。

Google JSON指南

成功响应返回数据

{
  "data": {
    "id": 1001,
    "name": "Wing"
  }
}

错误响应返回错误

{
  "error": {
    "code": 404,
    "message": "ID not found"
  }
}

如果您的客户端是JS，则可以使用if（响应中的“error”）｛｝来检查是否存在错误。

为了值得，我采取了不同的做法。成功的调用只有JSON对象。我不需要更高级别的JSON对象，它包含一个指示true的成功字段和一个包含JSON对象的有效负载字段。我只需要返回一个适当的JSON对象，该对象带有一个200或任何在200范围内适合于标头中HTTP状态的值。

但是，如果有错误（400系列中的某些错误），我会返回一个格式良好的JSON错误对象。例如，如果客户端向用户发送电子邮件地址和电话号码，其中一个错误（即我无法将其插入基础数据库），我将返回如下内容：

{
  "description" : "Validation Failed"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Invalid phone number."
  } ],
}

这里重要的一点是，“field”属性必须与无法验证的JSON字段完全匹配。这可以让客户确切地知道他们的请求出了什么问题。此外，“message”位于请求的区域设置中。如果“emailAddress”和“phoneNumber”都无效，那么“errors”数组将包含两者的条目。409（冲突）JSON响应体可能如下所示：

{
  "description" : "Already Exists"
  "errors" : [ {
    "field" : "phoneNumber",
    "message" : "Phone number already exists for another user."
  } ],
}

有了HTTP状态代码和JSON，客户机就拥有了以确定性方式响应错误所需的一切，并且不会创建新的错误标准来尝试完全替换HTTP状态代码。注意，这些错误只发生在400个错误的范围内。对于200范围内的任何东西，我可以返回任何合适的东西。对我来说，它通常是一个类似于HAL的JSON对象，但这在这里并不重要。

我想添加的一件事是在“errors”数组条目或JSON对象本身的根中添加一个数字错误代码。但到目前为止，我们还不需要它。

我曾经遵循这个标准，在客户端层非常好、简单、干净。

通常，HTTP状态为200，所以这是我在顶部使用的标准检查。我通常使用以下JSON

我还使用API的模板

dynamic response;

try {
   // query and what not.
   response.payload = new {
      data = new {
          pagination = new Pagination(),
          customer = new Customer(),
          notifications = 5
      }
   }

   // again something here if we get here success has to be true
   // I follow an exit first strategy, instead of building a pyramid 
   // of doom.
   response.success = true;
}
catch(Exception exception){
   response.success = false;
   response.message = exception.GetStackTrace();
   _logger.Fatal(exception, this.GetFacadeName())
}

return response;

{ 
  "success": boolean,
  "message": "some message",
  "payload": { 
     "data" : []
     "message": ""
     ... // put whatever you want to here.
  } 
}

在客户端层上，我将使用以下内容：

if(response.code != 200) { 
  // woops something went wrong.
  return;
}

if(!response.success){
  console.debug ( response.message ); 
  return;
}

// if we are here then success has to be true.
if(response.payload) {
  ....
}

请注意我是如何提前打破厄运金字塔的。

RFC 7807：HTTP API的问题细节是目前最接近官方标准的内容。