Open z-950 opened 4 years ago
由于是web api，主要考虑使用http、websocket的交互方式，也即http和websocket的api设计风格。
调用api，实际上就是信息传递。这里信息传递包括了请求和响应。
简单起见，先只考虑使用http协议调用api。
最初接触到前后端交互并自己进行开发，很理所当然的按最“简单”的方式设计api：所有请求数据都使用json并塞进http的body里，同时所有返回数据同样使用json塞进body里。
此处的“简单”并非真的简单，自行解析和处理数据，实际上不比利用http字段并使用相关函数处理简单。
后面了解到更多关于http的知识，并且了解到RESTful api规范，自然而然会使用RESTful风格的api。
迁移确实有成本，但下文会给出迁移成本低的理由。
前面提到了调用api实际上是信息传递。我们来看一下纯post和RESTful有哪里不一样。
首先可以肯定的是，经过设计，纯post能表达的信息量与RESTful是一样甚至更多的。
具体他们的区别：纯post是语义的聚合，RESTful是语义的分散。聚合，指的是大部分的信息都集中在http的body中。分散，指的是信息分散在http的各个字段中。
也即他们的区别是，对http使用方式的不同。纯post往往需要将http已有的字段重新定义一次，对http的利用率是较低的。纯post与RESTful风格的api比较，它们对path的设计也不同：纯post往往会把method放入path；而对于RESTful来说，method就是http的method。
也就是说，如果不了解http，那么设计纯post api会再设计出类似http的一套东西。那么为什么不学习http并直接转向RESTful风格呢？自行设计需要踩坑，效率通常比学习现有的东西低。即便是需求复杂，http的字段无法满足，http和RESTful的知识也能为设计提供思路。
JSON-RPC实际上就是比较完整的纯post信息交换设计。实际需要时可供参考。
由于websocket在正式通信过程中仅有消息内容，与http丰富的字段不同。协议本身限制了通信过程中只能使用类似http的纯post的方式。（socket.io有命名空间和事件实际上也是对消息内容的设计）
所以JSON-RPC同样适合websocket。
虽然RPC主要是在服务间进行，但浏览器也可以当作一个服务（渲染服务），并且通常只作为调用者。
RPC面向方法，RESTful面向资源，但无论怎么样，调用时都需要知道相关的地址（RPC的注册中心，RESTful的资源解析）和对应的参数，对于调用者来说，两者区别不大。
上面是经典的误解。RPC调用强调的是 函数调用，如何实现网络通信是函数调用的底层，也就是说，纯post（JSON-RPC）和RESTful都能作为RPC的网络交互设计风格。具体如何选择，看需求、接口的复杂程度。
这两者其实不应该相提并论，具体区别可以参考：如何理解RPC和REST （注：RESTful是REST使用http的一种实现）
由于是web api，主要考虑使用http、websocket的交互方式，也即http和websocket的api设计风格。
从http的语义角度入手
调用api，实际上就是信息传递。这里信息传递包括了请求和响应。
简单起见，先只考虑使用http协议调用api。
从纯post到RESTful
最初接触到前后端交互并自己进行开发，很理所当然的按最“简单”的方式设计api：所有请求数据都使用json并塞进http的body里，同时所有返回数据同样使用json塞进body里。
后面了解到更多关于http的知识，并且了解到RESTful api规范，自然而然会使用RESTful风格的api。
迁移确实有成本，但下文会给出迁移成本低的理由。
纯post和RESTful的语义
前面提到了调用api实际上是信息传递。我们来看一下纯post和RESTful有哪里不一样。
首先可以肯定的是，经过设计，纯post能表达的信息量与RESTful是一样甚至更多的。
具体他们的区别：纯post是语义的聚合，RESTful是语义的分散。聚合，指的是大部分的信息都集中在http的body中。分散，指的是信息分散在http的各个字段中。
也即他们的区别是，对http使用方式的不同。纯post往往需要将http已有的字段重新定义一次，对http的利用率是较低的。纯post与RESTful风格的api比较，它们对path的设计也不同：纯post往往会把method放入path；而对于RESTful来说，method就是http的method。
也就是说，如果不了解http，那么设计纯post api会再设计出类似http的一套东西。那么为什么不学习http并直接转向RESTful风格呢？自行设计需要踩坑，效率通常比学习现有的东西低。即便是需求复杂，http的字段无法满足，http和RESTful的知识也能为设计提供思路。
纯post和JSON-RPC
JSON-RPC实际上就是比较完整的纯post信息交换设计。实际需要时可供参考。
对于websocket
由于websocket在正式通信过程中仅有消息内容，与http丰富的字段不同。协议本身限制了通信过程中只能使用类似http的纯post的方式。（socket.io有命名空间和事件实际上也是对消息内容的设计）
所以JSON-RPC同样适合websocket。
关于RPC
虽然RPC主要是在服务间进行，但浏览器也可以当作一个服务（渲染服务），并且通常只作为调用者。
RPC和RESTful
RPC面向方法，RESTful面向资源，但无论怎么样，调用时都需要知道相关的地址（RPC的注册中心，RESTful的资源解析）和对应的参数，对于调用者来说，两者区别不大。上面是经典的误解。RPC调用强调的是 函数调用，如何实现网络通信是函数调用的底层，也就是说，纯post（JSON-RPC）和RESTful都能作为RPC的网络交互设计风格。具体如何选择，看需求、接口的复杂程度。
这两者其实不应该相提并论，具体区别可以参考：如何理解RPC和REST （注：RESTful是REST使用http的一种实现）