4种主流的API架构风格对比

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"两个单独的应用程序需要中介程序才能相互通信。 因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"为了快速、大规模地集成不同的应用程序，API使用协议或规范来定义那些通过网络传输的消息的语义和信息。这些规范构成了API的体系结构。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在过去，人们已经发布了多种不同的API架构风格。每个架构风格都有它独有的标准化数据交换的模式。这一系列的API架构风格的选项，引发了大量的关于哪种架构风格才是最好的争论。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/5d\/fe\/5df831c837786042195858a0276e01fe.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"不同时间的API架构风格，图源：Rob Crowley"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"今天，许多API的使用者将REST称作“消亡的REST”（REST in peace），并且为GraphQL感到欢欣鼓舞。而十年前，又完全是另一幅光景：REST是替代SOAP的赢家。这些观点的问题在于，它们的出发点只是为某种技术背书，而不是去考虑它实际的属性和特性如何与当前的需求相匹配。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/d6\/29\/d60faf458f95206f34ed88c074d09e29.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"四种API架构风格"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"RPC：调用另一个系统的函数"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"远程过程调用是一种允许在不同上下文中远程执行函数的规范。 RPC扩展了本地过程调用的概念，并将其放在HTTP API的上下文中。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最初的XML-RPC是存在问题的，因为很难确保XML有效负载的数据类型。因此，后来RPC API开始使用一个更具体的JSON-RPC规范，该规范被认为是SOAP的更简单的替代方案。gRPC是Google在2015年开发的最新RPC版本。gRPC可插拔支持负载均衡、追踪、运行状况检查和身份验证，它非常适合连接不同的微服务。"}]}]}