第四章：认证（1）
随着对API的理解，我们已经学到了一些东西。我们知道什么是客户端和服务器，知道它们使用HTTP进行交谈，知道它们使用特定的数据格式交谈以理解彼此的话。虽然我们知道它们如何交谈，但是还有一个非常重要的问题：服务器如何知道客户端就是它所宣称的那个呢？本章，我们浏览客户端向服务器证明自己身份的两种方式。
虚拟世界的身份
以前你可能已经在网站上注册过帐号。在这个过程中，网站会询问你一些私人信息，尤其是用户名和密码。这两部分信息成为你的身份标志。我们称之为凭证。当你再次访问这个网站的时候，你可以通过提供这些凭证来登录。
使用用户名和密码来登录是身份认证这一技术过程的例子。当你和服务器进行认证的时候，你通过向服务器提供只有你自己知道（起码我们希望只有你知道）的信息来证明自己的身份。一旦服务器知道你是谁，它会信任你，并且向你暴露账户的隐私数据。
API使用多种方式对客户端进行认证。这些方式称为认证方案。现在我们来看两种方案。
基础认证
上面的登录的例子就是最基础的认证方式。实际上，它的正式名称就是基础认证。虽然这个名字毫无新意，但是这个方案在API对客户端进行认证的时候是完全可以接受的。
基础认证只要求提供用户名和密码。客户端使用这两个凭证，组合成一个值，放置在HTTP的Authorization首部中和请求一起发送到服务器。
服务器收到请求后，查看Authorization首部，和自己存储的凭证进行比较。如果用户名和密码可以和服务器上的用户列表中的某一个匹配，服务器把它当成那个用户，完成请求。如果没有匹配的用户，服务器返回一个特定的状态码（401），告诉客户端认证失败，请求被拒绝。
虽然基础认证是一个有效的认证方案，但是它使用相同的用户名、密码来使用API和管理账户，这不是理想的方案。这相当于一个旅馆给了客人一把整栋建筑的钥匙而不是某个房间的钥匙。
和API类似，有些时候客户端的许可应该和账户所有者不同。比如，一个企业主雇佣了一个承包商，让他写一个使用收益API的程序。如果所有者轻易相信承包商的凭证就会有风险，因为不道德的承包商可能会修改密码，使得企业主不能使用自己的账户。很显然，如果能有一个替代方案就好了。
API密钥认证
API密钥认证技术可以克服共享凭证的缺陷，它要求使用唯一的密钥来访问API。本方案中，密钥通常是一长串的字母和数字，和账户所有者的登录密码是不同的。所有者将密钥给予客户端，类似于旅馆将一个房间的钥匙给予客人。
当客户端使用API密钥认证时，服务器知道应该允许客户端访问数据，但是现在可以有选择的限制管理功能，比如修改密码或者删除账户。有时候，密钥使用起来如此简单，用户都不需要给出密码。API密钥认证的灵活性就是，既可以限制控制权限，又可以保护用户的密码。
那么，API密钥在哪儿呢？也有一个专门的首部，是吗？很不幸，没有。和基础认证不同，API密钥认证不是一个由严格的规则构建的标准，它来自于web早期几个公司的构想。结果就是，API认证有点类似蛮荒的西部，不同的人有不同的实现方式。
随着时间的流逝，出现了一些常见的方案。其中之一是让客户端将密钥放在Authorization首部中，取代用户名和密码的位置。另一个是将密钥加到URL中（http://example.com?api_key=my_secret_key ）。不太常见的方法是将密钥放到请求主体中紧挨着数据。不管放在哪里，效果是一样的——它允许服务器对客户端进行认证。
译自
