什么是RESTful接口，今天彻底搞懂它

虽然这段时间在做iOS UI 自动化，但是在UI自动化中也需要请求后端的接口，通过接口返回的数据来定位或者寻找页面上的元素，这次顺便总结一下关于RESTful接口的内容。

在日常工作中总是听到RESTfull接口，那到底什么是TESTfull类型的接口呢？今天捋一捋，彻底弄明白它。

RESTful 接口是基于 REST（Representational State Transfer） 架构风格设计的 Web API 接口。它使用 HTTP 协议中的方法（如 GET、POST、PUT、DELETE）来操作资源，并遵循一系列约定，使得接口具有一致性、简洁性和可扩展性。

那ful是什么意思呢？
ful 是一个英语形容词后缀，用来表示某物“充满”或“具备”某种特征。在 RESTful 中，它只是用来形容符合 REST 设计原则和约束的系统或 API。所以，RESTful 并不代表一个单独的语法格式，而是指“完全遵循 REST 架构风格的”。例如，Helpful（有帮助的）——具有帮助性质的。这样的话就清晰多了，不然总以为ful也代表哪种类型呢。

接下来细聊聊RESTful：

【核心原则】
1、资源导向
一切皆资源，资源可以是数据（如用户、订单）或服务（如上传图片）。
每个资源通过唯一的 URI 表示（如 /users/123 表示 ID 为 123 的用户）。

2、无状态
客户端的每个请求都是独立的，服务器不会保存客户端的上下文信息。
请求必须包含完成操作所需的所有信息（如认证信息）。

3、统一接口
使用统一的 HTTP 方法操作资源：
GET: 获取资源。
POST: 创建资源。
PUT: 更新资源。
DELETE: 删除资源。
避免在接口中出现额外的动词（如 /getUser，应改为 /users/{id}）。

4、表现层状态转换（HATEOAS）
响应中包含相关链接，帮助客户端发现可用的操作（非强制）。
例如，获取用户时可以返回更新链接：

{
  "id": 123,
  "name": "John",
  "links": {
    "update": "/users/123",
    "delete": "/users/123"
  }
}

5、面向客户端的缓存
响应应标明是否可缓存，减少不必要的请求（如使用 Cache-Control）。

6、分层系统
客户端无需知道服务器的内部细节，服务器可以通过负载均衡、代理等方式优化性能。

【RESTful 接口的设计规范】
1、URI 设计
使用名词表示资源。
资源名使用复数形式（如 /users 而非 /user）。
层级关系通过路径表示（如 /users/{id}/posts 表示用户的帖子）。

GET    /users             获取所有用户
GET    /users/123         获取 ID 为 123 的用户
POST   /users             创建用户
PUT    /users/123         更新 ID 为 123 的用户
DELETE /users/123         删除 ID 为 123 的用户

2、HTTP 状态码
使用标准 HTTP 状态码表示请求结果：
200 OK：请求成功。
201 Created：资源创建成功。
204 No Content：删除成功，无返回内容。
400 Bad Request：请求参数有误。
401 Unauthorized：未授权。
404 Not Found：资源不存在。
500 Internal Server Error：服务器内部错误。

3、请求和响应格式
推荐使用 JSON 格式传输数据。
示例请求（创建用户）：

{
  "name": "John",
  "email": "[email protected]"
}

示例响应（获取用户）：

{
  "id": 123,
  "name": "John",
  "email": "[email protected]",
  "created_at": "2024-01-01T10:00:00Z"
}

4、过滤、排序、分页
提供查询参数支持数据筛选：

GET /users?age=30&country=US
GET /users?sort=created_at&order=desc&page=1&size=10

5、版本控制
可以通过 URL 或请求头实现：
URL：/v1/users
Header：Accept: application/vnd.example.v1+json

【RESTful 的优缺点】
优点
1、简单明了：
基于 HTTP 协议，易于理解和实现。
2、跨平台兼容：
无需依赖特定技术，支持多种语言和框架。
3、可扩展性：
分层架构支持大规模系统的扩展。
4、清晰的接口语义：
HTTP 方法与状态码约定明确，减少客户端开发成本。

缺点
1、无状态：
对于复杂的交互，可能需要客户端重复传递上下文信息。
2、效率问题：
不支持批量操作，多次请求可能增加延迟。
3、实现 HATEOAS 较复杂：
很多 RESTful 接口未完全遵循 HATEOAS 原则。

【示例代码】
后端示例（使用 Flask）

from flask import Flask, request, jsonify

app = Flask(__name__)

users = {
    123: {"name": "John", "email": "[email protected]"}
}

@app.route('/users', methods=['GET'])
def get_users():
    return jsonify(users)

@app.route('/users/', methods=['GET'])
def get_user(user_id):
    user = users.get(user_id)
    if user:
        return jsonify(user)
    return {"error": "User not found"}, 404

@app.route('/users', methods=['POST'])
def create_user():
    data = request.json
    new_id = max(users.keys()) + 1
    users[new_id] = data
    return jsonify({"id": new_id, "data": data}), 201

if __name__ == '__main__':
    app.run(debug=True)

客户端请求示例（Python）

import requests

# 获取用户列表
response = requests.get('http://127.0.0.1:5000/users')
print(response.json())

# 创建新用户
new_user = {"name": "Jane", "email": "[email protected]"}
response = requests.post('http://127.0.0.1:5000/users', json=new_user)
print(response.json())

【RESTful 的相关技术】
GraphQL：REST 的替代方案，更灵活，允许客户端指定需要的字段。
OpenAPI（Swagger）：用于描述 RESTful 接口的标准文档格式。
gRPC：高效的二进制通信协议，适合高性能服务调用。

RESTful 接口是现代 Web 开发的基础，虽然它并不是唯一的选择，但其简单性和通用性让它在众多应用中占据主导地位。

现在我们知道了什么是RESTfull风格的接口，那么哪些是不遵循RESTfull接口的类型呢？

不遵循 RESTful 规范的接口类型主要包括：
1、SOAP：基于 XML 的 Web 服务，结构严谨但较重。
2、GraphQL：允许客户端指定请求的数据字段，灵活但不符合 REST 的约束。
3、RPC：远程过程调用，不依赖 HTTP 的动词。
4、WebSocket：持久化连接协议，适用于实时通信。
5、JSON-RPC 和 XML-RPC：基于远程方法调用的轻量协议。
6、AJAX：异步通信技术，通常与 RESTful API 配合使用，但不构成完整的接口设计方法。