【Web Design The Missing Link】Chatty APIs

REST API比较“琐碎(chatty)”是一个普遍的误解。如果您的API过于琐碎，那是因为您为客户设计了错误的资源，而不是因为您使用了REST。“ REST意味着琐碎”的误解可能来自对REST-API必须看起来像完全标准化的关系数据库规范。在规范化设计中，每个不同的概念都有单独的资源，例如订单，客户，帐户等。如果仅定义这些资源，则想要向用户显示的UI客户端则必须执行许多GET才能检索订单，账目，客户，等等。幸运的是，除了规则数据库中的关系数据库必须看起来像这样之外，没有任何规则说REST接口必须看起来像这样。规范化的架构使更新变得简单，因此API的一种有用策略是把与规范化的架构关联的所有资源都定义出来，并为这些资源提供读取和更新功能。然后，您可以根据需要添加任意数量的只读资源以支持有效的客户端(非规范化)。这些非规范化资源也是真正的REST资源-它们具有实体的含义，具有URI等。它们的状态可能与其他资源的状态重叠，但这不是问题，并且此API至少要具有RESTful风格，比标准化的API有用得多。进行非规范化的其他方法也有，但是许多方法对于更新会更复杂，类似于通过关系数据库的视图进行的更新。

分页和局部的响应

部分响应使您可以仅向应用程序开发人员提供他们所需的信息。

例如，在Twitter API上发送一条推文请求。您将获得比典型的Twitter应用程序更多的东西-包括人员的姓名，推文的文本，时间戳，转发消息的频率以及许多元数据。

让我们看看几种领先的API如何处理应用程序开发人员所需的响应，其中包括率先提出部分响应概念的Google。

领英：

/people:(id,first-name,last-name,industry)

对“person”的请求返回ID、名字、姓氏和行业。LinkedIn使用这种简洁的（…）语法进行部分选择，我们发现这种语法很优雅，但应用程序开发人员可能很难理解，因为它不太常见。

Facebook：

/joe.smith/friends?fields=id,name,picture

Google：

?fields=title,media:group(media:thumbnail)

Google和Facebook也有类似的方法，效果很好。

它们每个都有一个可选的参数，称为fields，然后在其中放置要返回的字段的名称。如本例所示，您还可以在响应中放置子对象，以从其他资源中提取其他信息。

在以逗号分隔的列表中添加可选字段

Google的方法非常有效。

以下是使用这种方法从Dogs API中获取所需信息的方法：

/dogs?fields=name,color,location

这种方法行之有效的原因，在于：

1.它是非常易读的。
2.应用程序开发人员可以只选择给定时间的信息。
3.它减少了带宽问题，这对于移动应用程序很重要。

部分选择语法还可以用于包含相关资源，以减少获得所需信息的请求次数。

使应用程序开发人员可以轻松对数据库中的对象进行分页

在上一节中，我们展示了如何使用“next”，"previours"，"first"和"last"链接来允许API客户端非常简单地滚动浏览大型列表，而无需从复杂的URI模板构造URL。这通常足以处理集合，但是有时您可能希望允许客户对分页进行更明确的控制。

让我们看看Facebook，Twitter和LinkedIn的分页处理方式。Facebook使用"offset"和"limit"。Twitter使用"page"和"rpp（每页记录）"。LinkedIn使用"start"和"count"。

从语义上讲，Facebook和LinkedIn是一样的。也就是说，LinkedIn的开始和计数的使用方式与Facebook的偏移量和限制相同。

要从每个系统获取50到75的记录，您可以使用：

1.Facebook - offset 50 and limit 25
2.Twitter - page 3 and rpp 25 (每页的记录数)
3.LinkedIn - start 50 and count 25

我们喜欢使用limit和offset，尽管实现必须对数据值进行排序，并且所使用的数据库技术可能会导致(效率)折衷。