研发接口框架与开发接口服务系统，有着微妙的差异。前者更关注的是如何直接帮助接口开发人员更好的完成具体的项目开发，为工程师提供友好的接口和设计，减少学习和入门的成本，并间接尽可能能满足业务开发的需要。而后者，则重点聚集于领域业务的开发，面临的是业务逻辑处理与业务需求的快速迭代，同时兼顾客端调用、场景使用和系统之间的对接。
1 按技术分类
根据随着时间推移而使用的通讯协议的不同，可以得到相应协议背后不同实现方式的接口系统。较早期，采用的是SOAP（Simple Object Access Protocol）简单对象访问协议，并与XML可扩展标记语言一起，用于构建Web Service。我当时毕业论文设计采用的技术主要也是Web Service，但当前在实际商业项目中使用较少，只有极少数部分国内企业或国外的技术公司才能继续沿用Web Service。随后，行业内出现了RPC（Remote Procedure Call）远程过程调用协议，对应的开发类库有PHPRPC。相比于Web Service，PHPRPC会更为轻量。
现在，大部分接口系统使用的是路人皆知的HTTP协议，和比XML格式更为简洁的JSON格式一起，组合成：HTTP+JSON+API。这一实现方式，也是我从毕业后到现在，在从事职业开发过程中，见到使用范围最广的实现方式，包括但不限于开源框架、个人项目、初创公司、中小型接口系统、大型企业级中间层接口。因此，在本章的高可用接口服务系统中，我们也以此实现方式为主。
另一方面，如果基于接口系统的规范和设计理念进行分类，又可分为RESTful和微服务。RESTful是一种软件架构设计风格，它的核心思想是：万物皆为资源，并制定了相应的规范，更多内容推荐阅读《RESTful Web APIs》一书。而微服务是由Martin Fowler大师近几年提出来的概念，并广为流传和被引用。如果之前尚未接触过微服务的同学，可以关注微服务的这几点重要特质：
小，且专注于做一件事情
独立的进程中
轻量级的通信机制
松耦合、独立部署
微服务，可以说是当下接口系统混乱开发的一剂良药，为我们开发接口系统提供了很多启发性的帮助，所以我们这一章也是以微服务为根本的指导思想，致力于为客户端提供高可用的接口服务。
2 按客户端分类
前面我们按接口系统内部的实现技术或设计方式进行了技术分类，另一方面，也可以根据调用的客户端进行分类。而这种分类的做法，能让我们更加侧重于业务端、客户端的使用场景和业务需要进行考虑和设计。如果说，对于商家来说，“顾客就是上帝”，那么对于我们服务端开发工程师来说，也应秉持“客户端就是上帝”的服务态度。接口服务应该是服务于客户端，而不是限制客户端。不能是“我们服务端有什么，你们客户端就用什么”，而是应该提倡“我们客户端需要什么，我们服务端就提供什么”。
为什么这么说，是因为接口系统开发团队和客户端开发团队是隶属于不同的行政部门，在日常跨部门协作与沟通过程中，经常会发生优先级不一致或沟通不顺畅的情况，更糟糕的是有时会闹得两边的开发团队都不愉快。因此，作为服务端开发同学，我们应该始终以友好的态度，服务于我们的客户端，尽量提供客户需要的接口服务，不管内部实现有多困难。
言归正传，主要的客户端为：浏览器（包括PC端和M端）、App移动应用、服务端系统。
如果客户端是浏览器，那么我们需要对接的是前端开发工程师，他们主要使用的编程语言是Javascript，并且需要在兼顾PC版和M版的同时还要小心翼翼留意浏览器兼容性的问题。或是出于前后端分离的考虑，又或许是传统异步加载的做法推动，我们需要为浏览器提供JSON格式的数据接口，以便浏览器客户端可以进行Ajax调用。此时，基于客户端的特点，需要考虑是否存在跨域问题、是否需要支持JSONP并预防XSS攻击、是否需要全站切换HTTPS协议以及HTTP协议下兼容和过渡的考虑、是否适合为接口结果采用CDN缓存及其应急刷新机制……更重要的一点是对于安全性的设计，一方面要防止恶意爬虫对重要商业数据的抓取，另一方面要对用户的敏感个人信息获取与操作时需要进行登录态的身份校验。
如果客户端是App移动应用，那么安全性会相对高一些。因为可以在客户端和服务端之间进行签名校验，虽然也会有被逆向工程破解的可能，但相比于源代码的Javascript，使用Java开发的安卓应用以及使用Object-C/Swift开发的iOS应用，经过编译后的识别难度更大，破解更难。与此同时，移动应用可以说更为灵活，因为可以在很大程度上不受浏览器的约束和限制，除App通过WebKit等其他方式内嵌H5页面外。但对于移动应用，我认为最为值得关注的是不同版本的App应用与服务端接口之间的兼容性问题。一定要谨记，在开发App新版和升级接口系统的接口服务时，要考虑对旧App版本的兼容。如有必要，还应提供不同语言版本的SDK包，以便客户端快速开发和接入。
最后，我们还有一个特殊的客户端，它不是直接被终端用户使用的应用、页面或软件，而是同样运行在服务端的系统。也就是说，此时的客户端，它本身也是服务端系统，很可能也是接口服务系统。如果客户端的系统和服务端的接口系统都是同一公司内的系统，那么就需要考虑进行内网部署，甚至同机房部署，也就是我们常说的内网接口服务系统。如果是提供给外部公司或者第三方系统接入使用的，则要考虑是否搭建一个接口开放平台。例如国外的Facebook、Twitter、Amazon开放平台，又如国内的微信开放平台、支付宝开放平台、新浪微博开放平台等。这时，要考虑接入控制、权限控制、配套的计费系统以及控制台管理界面。
以上两种分类的方式，即按技术分类和按客户端分类，前者是帮助了我们梳理接口系统内部实现的要素和关键点，后者则是为我们搭建更加完善配套的接口服务生态系统而提供更多的思考。