一. API的分类
1. 进程内调用API
调用本地开发库
2. 本地进程间调用API
Linux IPC
Android IPC
3. 远程调用API
内网API——企业内网中的API
外网API——面向互联网的API
二.什么是架构风格
面向服务的架构（Service Oriented Architecture，简称SOA）
微服务架构（Microservices Architecture）
领域驱动设计（Domain-Driven Design，简称DDD）
三. 分布式应用的架构风格
1. 远程调用API
分布式对象（Distributed Objects，简称DO）
CORBA/RMI/EJB/DCOM/.NET Remoting
远程过程调用（Remote Procedure Call，简称RPC）
SOAP/XML-RPC/JSON-RPC/Hessian/Burlap/Flash AMF/Dubbo RPC
基于Google Protocol Buffer数据交换格式的各种RPC协议
基于Apache Thrift的各种RPC协议，例如唯品会的OSP
表述性状态移交（Representational State Transfer，简称REST）
将HTTP协议真正作为一种 应用协议 来使用，不再需要基于HTTP的各种RPC协议
RESTful API——符合REST架构风格要求的API
四. REST与RPC两种API调用风格的区别
1. REST对服务器端做抽象的基本单元是 资源，RPC对服务器端做基本抽象的单元是 过程。REST的建模是以名词为核心的，RPC的建模是以动词为核心的。
2. RPC中没有统一接口的概念。即使采用相同的协议，不同的API，设计风格可以完全不同。RPC也不支持操作语义对于中间组件的可见性。
3. RPC中无法使用超媒体，响应的内容只包含数据。REST中使用了超媒体后，可以实现很大粒度的交互，交互的效率比RPC更高。
4. REST支持数据流和管道，RPC不支持数据流和管道。
5. 因为使用了平台中立的消息，RPC的耦合度会比DO要小一些，但是RPC也常常会带来客户端与服务器端的紧耦合。REST中假如使用了超媒体，客户端与服务器端可以达到最小的耦合度。
五. RESTful API能解决的问题
1. 更加松耦合
改动RESTful API比改动RPC API更容易
2. 更好的可伸缩性
与基于HTTP的各种RPC协议相比，对HTTP的使用更有效率
便于利用HTTP缓存
支持数据流和管道 易于实现分层的缓存，提高了服务器端应用的可伸缩性
3. 有统一的设计和编程风格
服务器端
客户端
4. 测试更容易，可以使用各种HTTP测试工具
Postman/ Advanced REST Client
curl/wget
SoapUI Pro
Jmeter
ab/httperf/curl-loader
浏览器
5. 最好的互操作性
基于HTTP协议本身，几乎所有编程语言都能支持
六. RESTful API不能解决的问题
1. 不支持有状态的长连接，无法进行双向通信，实时性较差
2. 让服务器端应用开发人员早点下班
把轻松留给客户端应用开发人员，把困难留给自己——佛祖
把困难留给客户端应用开发人员，把轻松留给自己——人渣
3. 设计开发领域模型
DDD是设计开发领域模型的利器
DDD与REST是互补的关系，可相互支持
七. 对于HTTP的常见误解
1. 浏览器只支持GET/POST方法
HTML表单仅支持GET/POST方法，但是可以通过附加参数(例如_method)的方式模拟PUT/DELETE请求
XMLHttpRequest对象GET/POST/PUT/DELETE 4种方法均可支持
2. 未遵循HTTP协议的指导误用HTTP方法
GET方法：安全的、幂等的
POST方法：不安全的、不幂等的
PUT/DELETE方法：不安全的、幂等的
3. 过度使用GET方法
敏感信息位于URL中，不够安全
容易受到爬虫的伤害
4. 过度使用POST方法
例子：SOAP等RPC风格的调用协议
一个方法承担了过多职责
没有充分利用HTTP的优势
5. HTTP是一种RPC风格的协议
事实：HTTP其实是一种REST风格的协议
统一接口是REST与RPC两种风格协议的主要区别
6. HTTP是一种“传输”协议（transport protocol）
被错误翻译为“超文本传输协议”
事实：HTTP其实是一种“移交”协议（transfer protocol）。TCP才是传输协议，对传输这件工作已经做的很好了。
传输协议和移交协议的区别
传输协议做的是底层搬运比特之类的苦力活，不包含操作的语义
移交协议做的事情比传输协议更高级，包含了操作的语义
