3、接口协议基本原理：HTTP/HTTPS 基础
记得我刚转做接口适配那会儿，总觉得 HTTP 协议就是收发几个数据包。直到接手一个老系统迁移，才发现对基础理解不到位，排查问题能多花几倍时间。今天我们就从头把这些基本概念掰扯清楚。说白了，你后面所有 SDK 适配工作，都是在这套规则下跳舞。
3.1 HTTP 与 HTTPS：到底差在哪？
HTTP 是超文本传输协议。客户端发请求，服务端回响应。但它有个硬伤：数据是明文传输。我在项目中遇到过，内网调试时数据被中间代理篡改，排查了两个小时才发现是 HTTPS 没配好。
HTTPS 就是在 HTTP 外面套了一层 SSL/TLS 加密。你想想看，就像寄信加了密码本，中间人就算截获也看不懂。
我建议你记住三个核心区别：
- 加密与否：HTTP 明文，HTTPS 加密。这是本质差异。
- 端口不同：HTTP 默认 80，HTTPS 默认 443。
- 证书开销：HTTPS 需要 CA 证书，要么花钱买，要么自己签。我自己做测试时经常用自签名证书，但记得告知客户端跳过验证，否则会报证书错误。
3.2 请求/响应模型：一条消息的完整旅程
我们来看一次完整交互：
- 客户端发起请求——比如浏览器说“我要这个页面”。
- 服务端处理——收到后，找到资源或执行逻辑。
- 服务端返回响应——带着状态码和数据给客户端。
- 客户端解析使用——端侧拿到结果，渲染或持久化。
这个过程很简单。但我在老系统迁移时遇到过一个经典问题：原系统用 HTTP/1.0，每次请求都新建 TCP 连接。新 SDK 默认用 HTTP/1.1 的 keep-alive，服务端那边没适配，导致很多请求卡住。
3.3 状态码：服务端在告诉你什么？
状态码是服务端给客户的反馈。你想想看，就像你去办事，对方给你一个回执号。这个号代表你事情处理的状态。我个人习惯把常见状态码分成几组记住：
| 状态码 | 含义 | 我的经验 |
|---|---|---|
| 200 | 成功 | 最常见，表示请求被正确响应。 |
| 201 | 已创建 | RESTful 中创建资源用的较多。 |
| 301/302 | 重定向 | 我曾经被 301 循环跳转坑过，排查了半天才发现是缓存问题。 |
| 400 | 坏请求 | 通常是参数格式不对。排查时先看请求体。 |
| 401 | 未授权 | 没带 或者 过期。 |
| 403 | 禁止访问 | 有权限，但权限不够。 |
| 404 | 未找到 | 路径错了。我调试时经常打错一个字母。 |
| 500 | 服务器内部错误 | 服务端出异常了。需要看日志。 |
| 502/503 | 网关超时/服务不可用 | 迁移时注意，后端还在重启时会有这错误。 |
我建议你把这张表保存起来。SDK 适配里，看见 401 先查 ，看见 404 先查 URL，80% 的问题都能解决。
3.4 头部字段：藏在信封上的信息
HTTP 头部字段就像信封上的地址和标注。它控制着缓存、编码、认证、内容类型等等。我来列举几个会让你在适配中头疼的：
- Content-Type：告诉对方数据格式。比如
application/json表示 JSON，application/x-www-form-urlencoded是表单格式。我改过的一个老系统用的还是text/plain，新 SDK 不认，折腾了一下午。 - Authorization：认证信息。常见的是
Bearer <>。注意 的传递方式不要写死在 URL 里。 - Accept：客户端希望的返回格式。服务端根据它决定发 JSON 还是 XML。
- User-Agent：标识客户端类型。我调试时常改它来骗过服务端。
- Cache-Control：控制缓存行为。迁移时如果原系统有缓存策略，新 SDK 必须保持一致。
举个例子，你在 SDK 里发起一个 POST 请求：
POST /api/user/create HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache
{
"name": "张三",
"age": 30
}
看到没？第一行是请求行，后面是头部，空行之后是消息体。格式很严格，少了冒号或者空格，服务端可能直接返回 400。
3.5 RESTful 设计原则：让接口变得规范
RESTful 是一套接口设计规范。说白了，就是约定俗成的规矩，让大家写出来的接口风格统一。我刚开始学习时觉得它太教条，后来发现，遵循它之后，同事之间对接代码效率高了很多。
核心原则就几条：
- 资源定位：每个 URL 代表一种资源。比如
/users是用户集合，/users/1是具体的用户。 - 使用 HTTP 动词操作：GET 获取，POST 创建，PUT 修改，DELETE 删除。
- 无状态：每次请求都是独立的，服务器不保存客户端状态。
- 统一接口：所有资源都通过同样的方式操作。
举个例子：
GET /users # 获取所有用户
POST /users # 创建新用户
GET /users/1 # 获取 id=1 的用户
PUT /users/1 # 更新 id=1 的用户
DELETE /users/1 # 删除 id=1 的用户
看着很清晰吧？我参与过的一个老系统把删除操作写成 GET /deleteUser?id=1，复用查询接口做删除。迁移时改了好久。所以我建议你，新项目一开始就定好 RESTful 风格，后面省心很多。
最后我来总结一下这一章。HTTP/HTTPS、请求响应模型、状态码、头部字段、RESTful——这几块内容，是接口协议的根本。你后面写 SDK 封装、迁移老系统、调试接口，绕不开这些知识。我作为过来人，最深刻的体会是：基础越扎实，以后踩的坑越少。