第三章：数据格式

目前为止，我们已经知道HTTP是网上的API的基础，也知道要使用这些API，我们需要了解HTTP是如何工作的。本章我们来看一下API提供的数据，看一下这些数据是怎么组织的，以及HTTP是如何实现这些格式的。

表示数据

当人之间交换数据的时候，展现数据的可能性只受限于人类想象力。回忆一下，上一章披萨店的例子——他们可能如何组织菜单呢？可能是纯文本的列表；可能是一系列带有说明文字的图片；也可能只有图片，国外的顾客可以通过点图片来下单。

设计良好的格式可以使这些信息对目标读者最容易理解。

算机需要将数据组织成另一台计算机可以理解的格式。通常来说，这意味着一些文本格式。现代API使用最多的格式是JSON（JavaScript Object Notation）和XML（可扩展标记语言）。

JSON

很多新的API采用JSON格式，因为它是由流行的JavaScript编程语言创建的，在web上非常普遍，web应用的前端和后端以及web服务都可以使用。JSON是一种非常简单的格式，包括两部分：key和value。key代表被描述的对象的某种属性。一个披萨订单可以是一个对象。它有属性（key），比如外皮的类型，配料和订单状态。这些属性都有相应的值（薄皮，意大利香辣肠和正在派送）。

现在我们看一下这样一个披萨订单以JSON描述是什么样子的：

{
    "crust": "original",
    "toppings": ["cheese", "pepperoni", "garlic"],
    "status": "cooking"
}

在上面JSON的例子中，key是左面的单词：toppings, crust和status。它们告诉我们披萨订单包含哪些属性。value是右边部分。这些是订单的实际细节。

图1 JSON key和value

如果你从左到右阅读上面的一行，你几乎可以把它当作一个英文语句。以第一行为例，我们可以这样阅读“披萨的外皮是原始样式”。第二行也可以这样读——在JSON中，一个以方括号开始和结尾的值是一个值的列表。所以，我们按这样的顺序阅读第二行，“订单的配料是：奶酪，意大利辣香肠和大蒜。”

有时候，你希望将一个对象作为key的value。我们增加客户的详情来扩展订单，你看到的应该是这样的：

{
  "crust": "original",
  "toppings": ["cheese", "pepperoni", "garlic"],
  "status": "cooking",
  "customer": {
    "name": "Brian",
    "phone": "573-111-1111"
  }
}

更新后的版本，我们看到增加了一个新的key，“customer”。这个key的值是另一个key和value的集合，这个集合提供了下订单的顾客的详情。酷毙了，是吧？这种叫做关联数组。不要让专业术语吓到了——一个关联数组就是一个嵌套的对象而已。

XML

XML大约从1996年就有了。随着时间的发展，已经成为一种非常成熟且强大的数据格式。像JSON一样，XML提供一些简单的积木，API的创建者可以使用它们创建自己的数据结构。主要的积木被称为结点。

我们看看我们的披萨订单在XML中是什么样子的：

<order>
    <crust>original</crust>
    <toppings>
        <topping>cheese</topping>
        <topping>pepperoni</topping>
        <topping>garlic</topping>
    </toppings>
    <status>cooking</status>
</order>

XML总是以一个根结点开始，在我们的例子中是“order”。order中有很多“子结点”。结点的名字告诉我们订单的属性（就像JSON中的key），结点中的数据是实际的细节（就像JSON中的value）。

图2 XML结点和值

你也可以从XML中推断出英文语句。看“crust”这一行，我们可以这样读，“the crust for the pizza is original style”。注意配料列表中的每一个项目是怎么用结点包装起来的。你可以看到XML格式比JSON需要更多的文字才能进行通信。

HTTP中如何使用数据格式

我们已经看过几种可用的数据格式，我们需要知道如何在HTTP中使用它们。为了使用它们，我们需要再次回到HTTP的一个基础概念：首部。在第二章中，我们首部是关于请求和响应的信息列表。有一个首部用来说明数据使用了哪种格式：Content-Type。

当客户端向服务器发送的请求中包含了Content-Type首部，它告诉服务器请求主体中的数据使用了特定的格式。如果客户端希望向服务器发送JSON数据，它会将Content-Type设置为“application/JSON”。服务器收到请求，看到Content-Type后，它首先会检查自己是否理解这种格式。如果可以理解的话，它就知道如何阅读这些数据。同样，当服务器向客户端发送响应时，它会设置Content-Type来告诉客户端如何阅读响应的主体。

有时候，客户端智能使用一种格式。当服务器返回这种格式之外的任何东西，客户端会失败，并且抛出错误。幸好，第二个HTTP首部可以挽救这个问题。客户端可以设置Accept首部，告诉服务器可以接受哪些数据格式。如果客户端只能使用JSON，它可以将Accept首部设置为“application/JSON”。服务器使用JSON返回响应。如果服务器不支持客户端请求的格式，它会返回一个错误，告诉客户端请求无法工作。

有了这两个首部，Content-Type和Accept，客户端和服务器可以使用它们理解和需要的数据格式进行工作了。

图3 数据格式首部

译自

Chapter 3: Data Formats