3. HTTP 协议基础回顾：请求方法与状态码

在物联网采集平台中，设备与服务器、客户端与 API 之间的每一次数据交换都基于 HTTP 协议。理解 HTTP 的核心要素——请求方法、状态码、请求头与响应体——是构建可靠采集接口的前提。本节将系统回顾这些基础概念，并聚焦于它们在物联网场景下的典型应用。

3.1 HTTP 请求方法：物联网中的“动作”语义

HTTP 定义了一组请求方法，用于指示对资源期望执行的操作。在 RESTful 风格的物联网 API 中，最常用的四种方法对应着 CRUD（创建、读取、更新、删除）操作。

3.2 HTTP 状态码：服务器响应的“信号灯”

状态码是服务器对请求处理结果的数字标识。物联网采集平台需要精确区分成功、客户端错误和服务器错误，以便设备或采集程序做出正确决策。

3.3 请求头与响应体格式

HTTP 请求和响应由起始行、头部（Headers）和消息体（Body）组成。头部携带元数据，体部承载实际数据。

3.3.1 常见请求头

• Content-Type：指明请求体的媒体类型。物联网 API 常用 application/json。
• Authorization：携带认证凭证，如 Bearer Token，用于设备身份校验。
• Accept：告知服务器客户端期望的响应格式。
• X-Request-ID：自定义头，用于链路追踪和日志关联。

3.3.2 常见响应头

• Content-Type：响应体的媒体类型。
• Location：201 Created 响应中，指向新创建资源的 URI。
• Retry-After：告知客户端在多长时间后重试，常用于限流场景。

3.3.3 响应体格式

物联网平台通常采用 JSON 作为数据交换格式。一个规范的响应体应包含状态、消息和数据三个部分。

// 成功响应示例 (200 OK)
{
  "code": 200,
  "message": "success",
  "data": {
    "device_id": "sensor_001",
    "temperature": 25.6,
    "humidity": 68.2,
    "timestamp": "2025-03-21T10:30:00Z"
  }
}

// 错误响应示例 (400 Bad Request)
{
  "code": 400,
  "message": "invalid parameter: temperature must be a number",
  "data": null
}

3.4 HTTP 请求-响应流程示意图

下图展示了一个物联网设备通过 HTTP POST 上报数据，并接收服务器 201 Created 响应的完整交互流程。

3.5 物联网 API 状态码决策逻辑

在采集平台后端，根据不同的处理结果返回对应的状态码，是保证客户端正确重试和错误处理的基础。下图展示了服务器内部的状态码决策流程。

3.6 物联网场景中的 HTTP 最佳实践

• 统一错误体结构：无论返回 400、404 还是 500，响应体都保持 { code, message, data } 格式，便于客户端统一解析。
• 合理使用状态码：不要将所有错误都返回 500。参数错误用 400，资源不存在用 404，权限不足用 403，服务器内部异常用 500。
• 请求头携带上下文：在请求头中传递设备 ID、API 版本号、请求追踪 ID，便于服务端日志分析和问题定位。
• 避免 GET 请求携带请求体：GET 请求不应包含 Body，所有查询参数应放在 URL 的 Query String 中。