在身份和拜访控制方面，我们往往会基于有效的凭证，来授予央求关于API资源的拜访权限。此类凭证包括：OAuth2.0拜访令牌、API密钥、基本身份验证的标头、客户端证书等外容信息。例如，任何具有无成效户名和密码的用户，都应当被允许在某个电商网站上阅读产品的详细信息。但是，只要那些具有管理员权限的用户才被允许更新产品的详细信息。当然，拜访控制也不只限于基于角色的反省，有时一些系统还会依据日期和时间（如：仅允许在任务日的8点到17点之间拜访），或基于央求的配额等方面停止拜访控制。
上文提到的API网关，可专门担任此类身份验证与授权反省。它们将各种系统安全需求笼统成标准的标准和协议，并允许客户端运用经过该机制（例如OAuth2.0）与之交互。
另外，下游或后端API有时分也需求了解拜访API用户的详细信息，以便执行其固有的逻辑。因此，有些API网关还会担任将用户的上下文，转发到下游或后端API上。
为辨认形式和检测异常而继续学习
光有防火墙和复杂的身份验证，是不足以检测API密钥或拜访令牌等凭据入侵的。前文提到了OAuth2.0，其拜访令牌的时间跨度相对较短，即使被黑客入侵，也只能在令牌过时之前有效。那么为了避免令牌在这么短的时间内被被盗，我们需求经过MFA（多要素身份验证）来进一步执行身份验证。
值得一提的是，API网关本身并不能保护系统免受异常攻击，它只是在横跨不同网络的群集之间避免共享用户的形状和拜访记载。因此，API网关需求与某些机器学习和数据形式剖析类型的方案一同运用。这些方案将可以跟踪用户的拜访历史记载和形式，并在出现成绩时向API网关收回警报，以便网关采取适当的措施。
五、可扩展性
API的扩展
如今，许多组织正在将他们的基础架构迁至云端，以按需付费的方式在第三方IaaS提供商（如：AWS、Google、以及Azure等）上运转全部或部分IT效劳。云原生架构的一项关键特征是可以提供自动扩展的效劳。那么我们的API及其网关也要具有此类特征。在此方面，我们需求思索到如下三点：
启动的延迟。
对其他系统的依赖性。
形状的复制。
通常，进程启动的速度越快，就越容易扩展。例如：某个进程需求30秒或更长时间才能启动，那么它就至少需求在30秒之前末尾扩展，以便系统可以及时启动并运转该进程。也就是说，假设某个进程启动需求的时间越长，您越需求提早扩展该进程。
有时分，某个进程无法自行扩容，此时您的API及其网关就需求依赖于其他辅佐类进程来完成。可见，您的API及其网关越独立，就越容易完成系统的扩展。另外，假设您的API及其网关需求维持外部、外部形状的分歧性，那么在扩展API时则需求思索如何复制系统的形状。与常规有形状系统相比，独立且有形状的API更易于自动扩展。
六、可用性
如今系统的可用性变得越来越重要了。虽然云效劳为我们的全体业务提升了鲁棒性，但是我们依然需求思索如何为API构建和装备具有一定的弹性系统，其中包括：
当系统出现缺点时，我们可以快速地恢复系统。
数据中心、全体区域、以及IaaS效劳的高可用性。
通常而言，我们很容易经过备份的方式满足单个系统中的每个效劳器、进程、文件系统、以及数据库的高可用性。但是，我们该如何应对整个数据中心或区域的缺点呢？我们通常需求在多个数据中心的位置上同时部署本人的API。而为了增加API构建、部署和维护的开支，我们往往需求经过尽能够多的自动化，来轻松有效地完成跨多个可用区域的数据复制。
由于系统存在的依赖性越多，其缺点恢复的难度就越大，因此许多系统都采用了具有自动修复才能的原生云端容器平台（如：Kubernetes），以降低缺点恢复的难度。不过，云效劳提供商本身的可用性最近也遭到质疑。想象一些：假设某个IaaS提供商的特定效劳发作了全球范围内的中缀，我们能否可以切换到其他IaaS处呢？例如，能否可以经过协作，我们将运转在AWS RDS某个区域的中缀业务切换到Azure的备份上？
如今，曾经有企业成功地在不同地域的IaaS提供商之间部署了本人的API。他们在不同的IasS上构建了散布式的可扩展系统，并经过火担全体系统负载的方式，完成了按需扩展与付费。
七、维护
我们可以从如下三个方面及时得知API有效性与功用:
运营监控
缺点诊断
业务监控
运营监控
运营监控关于API的正常运转，以及业务颠簸展开都是至关重要的。您需求在真正发作成绩之前就能判定缺点，予以处置，并消弭负面影响。例如：您的某个效劳或API出现了耗尽内存的状况，那么您就可以及时经过监控系统，检测到API关于内存运用率的极速增长，并在超过既定阈值的时分收到警报信息。而针对此类状况，我们往往可以经过扩展出更多的实例进程，来为基本缘由的查找和处置博得时间。
缺点诊断
关于事情的缺点诊断，及时搜集到缺点的相关数据是十分重要的。首先，我们需求从API和效劳处搜集到一切的运转时日志，经过对其停止索引，以便快速轻松地停止搜索，进而获取和辨认特定时间段发作的系统事情。在掌握事情日志之后，我们需求依据“蛛丝马迹”按需启用进一步的日志跟踪，以获取内存dump、网络等方面的信息。
您应该努力于构建可以以理想的零缺点率或最小的客户影响率停止缺点扫除的系统。这样做的一种盛行形式是将一组缺点节点隔离到一个独自的群集中，该群集要么不接纳客户的流量，要么仅接纳一小部分流量，以方便执行缺点扫除。
业务监控
现如今，许多企业都将对外提供API作为本身业务的主要增长点。因此，他们需求经过权衡API的运用，来决议组织业务的策略。为此，我们需求一个系统来捕获与完成与以后业务目的相关的一切API数据，其中包括：前一个月新API的运用者数量，基于现有API构建的新运用的数量，调用以后API的运用在其照应时间上的改良，特定区域内API用户的增长等方面。我们经过深化开掘API的调用，以权衡业务KPI的表现。
总结
经过上述讨论，希望您曾经了解到：
为客户提供价值是我们的第一要务。基于微效劳的架构可以以更快的速度交付出牢靠的软件，从而为客户提供更高的价值。
API是企业创立数字体验的架构基础。
现代化API往往是自下而上开发的，因此开发人员和CI/CD流程尤为重要。
API的管理在确保正确地交付API方面发扬着重要的作用。
组织应具有将效劳的异构集合组合到不同API中的才能。
API的安全性主要包括：内容反省，身份验证和授权，以及异常形式的剖析。
API应该具有可扩展性，以满足云原生运用的需求。
我们需求经过云效劳给API带来更高的可用性。
关于API的监控是企业继续开展的重要保障。
原文标题：Delivering a Successful API: Know What it Takes，作者：Nuwan Dias
【51CTO译稿，协作站点转载请注明原文译者和出处为51CTO.com】
【编辑引荐】
不容错过的Pandas小技巧：万能转格式、轻松兼并、紧缩数据
了解微效劳失败的这11个缘由，预防和及时止损！
高功用前端架构处置方案
一款 0 门槛轻松易上手的数据可视化工具
微效劳中，如何交付一款成功的API
(责任编辑：admin)