|
@@ -3,18 +3,13 @@ RPS_TOC
|
|
|
|
|
|
canonical={canonical}
|
|
|
|
|
|
-// tag::main[]
|
|
|
-
|
|
|
== RPS_KEY_DEF
|
|
|
|
|
|
-* 前端
|
|
|
-** 贴近真实用户侧的软件,主要与后端服务交互并将其可视化为用户提供界面的软件,通常在用户侧的设备上运行,
|
|
|
-* 通信
|
|
|
-** 两个不在一个内存空间甚至不在一个设备上运行的程序,需要通过网络来进行通信以表达请求、传递数据的过程。
|
|
|
-* 通信协议
|
|
|
-** 对软件通信进行了一定的规范和约束定义,使得软件交互过程更加清晰、明了,这里指软件在应用层交互的协议如HTTP协议、FTP协议、gRPC。
|
|
|
-* 序列化/反序列化
|
|
|
-** 这里的序列化指软件运行时内存态数据转化为通信协议所需数据的过程。
|
|
|
+[horizontal]
|
|
|
+前端:: 贴近真实用户侧的软件,主要与后端服务交互并将其可视化为用户提供界面的软件,通常在用户侧的设备上运行,
|
|
|
+通信:: 两个不在一个内存空间甚至不在一个设备上运行的程序,需要通过网络来进行通信以表达请求、传递数据的过程。
|
|
|
+通信协议:: 对软件通信进行了一定的规范和约束定义,使得软件交互过程更加清晰、明了,这里指软件在应用层交互的协议如HTTP协议、FTP协议、gRPC。
|
|
|
+序列化/反序列化:: 这里的序列化指软件运行时内存态数据转化为通信协议所需数据的过程。
|
|
|
|
|
|
== 🆚 现代常见通信协议比较
|
|
|
|
|
@@ -22,13 +17,13 @@ canonical={canonical}
|
|
|
|
|
|
=== Restful API
|
|
|
|
|
|
-**REST**:表述性状态传递 Roy Fielding博士在2000年他的博士论文中提出REST(Representational State Transfer)风格的软件架构模式,REST出现后,迅速取代了复杂而笨重的SOAP,成为Web API的标准,
|
|
|
-**Restful**:REST 风格的设计。
|
|
|
-**Restful API** REST风格的应用程序接口。link:api.html[Shoulder API 规范]中有一定说明。
|
|
|
+**REST**:: 表述性状态传递 Roy Fielding博士在2000年他的博士论文中提出REST(Representational State Transfer)风格的软件架构模式,REST出现后,迅速取代了复杂而笨重的SOAP,成为Web API的标准,
|
|
|
+**Restful**:: REST 风格的设计。
|
|
|
+**Restful API**:: REST风格的应用程序接口。link:api.html[Shoulder API 规范]中有一定说明。
|
|
|
|
|
|
-基于HTTP/1协议设计,由于其足够简单,几乎被互联网完全认可,是互联网的通用协议,绝大多数设备均支持,协议穿透性好。由于其基于HTTP的文本协议,与其他二进制通信协议相比较重,性能自然差一些。
|
|
|
+NOTE: 基于HTTP/1协议设计,由于其足够简单,几乎被互联网完全认可,是互联网的通用协议,绝大多数设备均支持,协议穿透性好。由于其基于HTTP的文本协议,与其他二进制通信协议相比较重,性能自然差一些。
|
|
|
|
|
|
-适用于系统的开放边界,与第三方交互的地方。
|
|
|
+TIP: 适用于系统的开放边界,与第三方交互的地方。
|
|
|
|
|
|
=== Dubbo
|
|
|
|
|
@@ -59,6 +54,3 @@ canonical={canonical}
|
|
|
** 有性能需求场景、且在考虑调用方与服务提供方开发成本的前提下,优先选择 dubbo/gRPC 系列
|
|
|
** 通用场景可以选择 Restful 进行快速迭代。
|
|
|
|
|
|
-
|
|
|
-
|
|
|
-// end::main[]
|