HTTP、RESTFul、RPC
HTTP是一种网络传输协议，它定义了：
请求响应模型
无状态协议
标准方法（GET、POST、PUT、DELETE）
状态码（200、4xx、5xx）
HTTP报文结构如下：
GET /users/123 HTTP/1.1 # 请求行（方法+URI+协议版本）
Host: api.example.com # Header
Accept: application/json
HTTP/1.1 200 OK # 状态行
Content-Type: application/json # Header
{"id":123,"name":"Alice"} # Body（响应数据）RESTFul是一种API设计风格，它是基于HTTP协议的，它要求：
API设计使用标准的HTTP方法，即GET、POST、PUT、DELETE
用URI作为唯一标识资源，例如
chymfatfish.cn/users/123，并且为不同的方法规定了不同的资源标识方法，例如GET方法中带参的chymfatfish.cn/user/123?sex=male请求/响应包含足够信息处理数据（如Content-Type: application/json），通过Header和Body实现
无状态：服务端不保存客户端状态，每次请求包含完整上下文
RESTFul API设计示例如下：
### 1. 获取用户（资源标识 + GET方法）
GET /users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
### 2. 创建用户（资源集合 + POST方法）
POST /users HTTP/1.1
Content-Type: application/json
{"name": "Bob", "email": "bob@example.com"}
### 3. 更新用户（资源标识 + PUT方法）
PUT /users/123 HTTP/1.1
Content-Type: application/json
{"name": "Alice Updated"}
### 4. 删除用户（资源标识 + DELETE方法）
DELETE /users/123 HTTP/1.1最后看RPC，经常看到这个词汇，但RPC到底是什么
其实RPC就像spring，也是一种框架，但它是一种框架模板，具体实现有很多
RPC框架的目标就是为了简化微服务架构的跨服务调用，希望可以像写接口一样实现服务之间的调用，使用RPC框架后，可以通过一些配制文件，或注解，屏蔽调一些网络通信过程中的重要环节，而这些环节也正是RPC提供的能力，同样也是传统HTTP接口调用过程中的一些关注点：
通信协议选择：例如CSE支持RestFul风格的HTTP协议，Dubbo支持Dubbo协议
请求/响应的序列化：RPC应该实现序列化方法，例如JSON、Protobuf等
服务发现：RPC框架往往配合注册中心使用，从注册中心中请求服务地址
负载均衡：内置客户端负载均衡
容错熔断：集成Hystrix等
调用代理：自动生成客户端代理类，让远程调用在代码层面与本地调用一致
如果没有RPC框架，我们调用一个外部接口，可能需要完成的步骤包括：
封装一个标准的HTTP协议请求，并将其序列化为JSON形式，作为准备发送的网络请求数据
自行找到需要调用的服务端接口地址，并且要提防对端接口地址变化
如果对方服务器是多容器部署，需要考虑其容器压力，自行通过list轮询调用（即负载均衡）
考虑调用过程中的异常，增加容错机制，防止调用失败导致业务失败
如果使用RPC框架，我们可能只需要一个注解，就能将一个类变成具备远程调用能力的类，业务中进行远程调用，只需要调用这个类的方法，就像本地调用一样，而RPC就会生成代理类，完成一些列的网络调用步骤
评论区