最近突然对于API以及API管理相关的内容感兴趣，于是上18摸的 API Management网站 下载了一本《APIs For Dummies》的IBM版本做入门的学习。当看到其中的APIs versus services一节，对于API与服务差异的解释，很是清晰，也解开了自己一直以来的疑问。尤其是利用汽车来比喻API与Service的异同，真令人印象深刻。不惜做一回搬运工，把书中的内容做个归纳。 SOA的核心是服务（Service）,单纯从技术的角度来看，其实API也是一种服务。但是否API就等于服务呢，这又不尽然。服务与API最大的差别，是它们设计目标的不同。API总是设计用来吸引预期的使用者，当使用者的需求发生改变API也相应改变。与此相反，对于服务的设计，全局的成本和稳定性往往更加重要。使用汽车来比喻的话，API的设计是赛车，注重于外观和使用，而服务的设计是常规的汽车，更着眼与成本和大批量的生产。 APIs and services address different concerns API的产品本质是面向特定的使用者，对于使用者来说，使用API意味着快速、方便与极短的学习曲线。至少从服务提供者的角度来看，这些设计标准是传统的服务与API的根本性差别。 对服务提供者来说，重用包含于API交付的努力中；对于API的使用者，重用是关乎他们软件的交付速度，不管需要为作为软件一部分的API付出多大的代价。 对于服务提供者来说，共享是关乎效率；对于API使用者，共享是是否方便（如果不方便，该API将没人使用） 对于服务提供者来说，封装是更少的改变；对于API使用者，封装是更短的学习曲线（如果接口太复杂，API将没人使用） 有多少SOA项目没有因为服务提供者和服务使用者间因为服务接口由什么组成的冲突而停滞的？一方面，一个移动应用开发者希望API对于她的应用要足够简单；另一方面，后台团队希望大家使用相同的标准化的服务和数据模型。有没有一种既能满足需求，又不会产生高昂费用的强制双方接受的权宜解决方法呢？ API与服务的结合 SOA是屏蔽服务使用者与后端变化的方法。但是谁能为需求不断变化的前端多渠道应用的服务提供者提供保护呢？结合API和服务可使你沉着应对剧变的环境。服务是由服务提供商整理的应用域的基本功能，API是在这些功能（服务