HTTP 到底是什么：请求、响应、资源和 URL

第01篇_HTTP 到底是什么请求、响应、资源和 URL[!abstract] 先不写 PLC 状态机也不背术语。从上位机读取设备状态这个需求出发把 Client、Server、资源、URL、请求、响应、方法、状态码、Header 和 Body 放进同一笔真实对话。适合谁收藏第一次系统理解 HTTP 的 PLC 工程师。已经会调用通信功能块但分不清 TCP 连通与 HTTP 完整事务的人。需要建立后续 Server、Client 学习坐标的读者。[!note] 本篇位置 基础认知第 1/4 篇主系列第 01/28 篇。现场问题PLC 里有运行状态、产量和报警记录上位机需要读取它们。双方当然可以私下约定READ_STATUS和1,1250,0但一旦增加查询条件、写入参数、错误结果和不同数据格式这套私有字符串就会迅速失去边界。HTTP 解决的不是“怎样控制 PLC”而是不同程序怎样用统一格式描述一件事请求方要操作哪个资源、准备做什么、携带了什么内容响应方是否处理成功、返回了什么、消息到哪里结束。先给结论HTTP 是应用层的请求/响应协议。Client 主动发送一条完整请求Server 针对一个资源返回一条完整响应URL 标识资源方法表达操作意图状态码表达处理结果Header 描述消息Body 承载内容。读图重点这张图只压缩本篇的判断路径。读图时先找“Client / Server”对应的输入边界再沿着“状态码、Header、可选 Body”检查状态怎样推进最后用“说明处理结果以及返回什么”确认输出是否已经形成验收证据。把对象和边界分开对象或阶段工程职责现场观察点Client / Server发起请求 / 返回响应同一台 PLC 可以同时承担两种角色Resource / URL被操作的对象 / 对象地址/api/status标识设备状态资源Request方法、目标、Header、可选 Body说明想做什么以及携带什么Response状态码、Header、可选 Body说明处理结果以及返回什么把一问一答逐行读完上位机读取 PLC 状态时可以发送GET /api/status HTTP/1.1 Host: 192.168.1.20:8088 Connection: close第一行表示“使用 HTTP/1.1以 GET 方式读取/api/status资源”。Host指明本次请求对应的主机空行表示 Header 到此结束。这个 GET 没有 Body。PLC 返回HTTP/1.1 200 OK Content-Type: text/plain Content-Length: 7 Connection: close running状态码 200 表示这一条请求已经成功处理。Content-Type说明 Body 是普通文本Content-Length: 7说明 Body 正好是 7 个字节。running才是返回内容。写入设定值时消息会多出 BodyPOST /api/setpoint HTTP/1.1 Host: 192.168.1.20:8088 Content-Type: application/json Content-Length: 15 Connection: close {value:125.5}JSON 只是 Body 的一种数据格式。TCP 负责传字节HTTP 负责定义请求和响应JSON 负责表示 Body 内的数据PLC 应用负责决定这份数据能否改变设定值。四者不能互相替代。从协议约束到代码职责协议约束HTTP 是应用层的请求/响应协议。Client 主动发送一条完整请求Server 针对一个资源返回一条完整响应URL 标识资源方法表达操作意图状态码表达处理结果Header 描述消息Body 承载内容。 这条结论先限定消息什么时候成立再限定哪个角色可以消费结果。若绕过协议边界直接驱动业务半包、超时、重复执行和连接残留就会进入应用层。工程抽象请求第一行由方法、请求目标和 HTTP 版本组成例如GET /api/status HTTP/1.1。Header 结束后必须有空行如果请求带 Body消息还要用 Content-Length 或 Transfer-Encoding 说明 Body 边界。响应第一行改为版本、状态码和原因短语例如HTTP/1.1 200 OK。状态码不是网络状态。TCP 已连接后仍可能收到 400说明通道成立但请求格式不合法也可能收到 404说明请求合法但资源不存在。只有把传输、协议和业务结果分开后面的 PLC 状态机才不会只剩一个含义模糊的bError。Client / Server工程职责是“发起请求 / 返回响应”。它不能只停留在命名层面运行时必须能通过“同一台 PLC 可以同时承担两种角色”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。Resource / URL工程职责是“被操作的对象 / 对象地址”。它不能只停留在命名层面运行时必须能通过“/api/status标识设备状态资源”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。Request工程职责是“方法、目标、Header、可选 Body”。它不能只停留在命名层面运行时必须能通过“说明想做什么以及携带什么”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。Response工程职责是“状态码、Header、可选 Body”。它不能只停留在命名层面运行时必须能通过“说明处理结果以及返回什么”观察到输入、状态或结果否则这一层即使有代码也没有形成可验证边界。程序单元本篇主证据来自ST_HttpRequest.st中以TYPE ST_HttpRequest为定位点的连续源码。这里不是为了展示语法而是把协议约束落到确定程序单元输入先进入结构体或缓冲区状态机只在本周期处理可确认的部分长度和结束条件决定能否前进错误码与指标负责把失败原因带出对象边界。这样一来“HTTP 管理请求与响应不直接管理 PLC 变量。”可以在代码、在线变量和外部报文之间逐项对照而不是依赖经验猜测。本篇核心源码片段下面两段代码来自同一个真实文件ST_HttpRequest.st以TYPE ST_HttpRequest为中心连续截取没有改写变量、删除分支或用伪代码替代。第一段用于确认入口与前置条件第二段用于确认状态、边界和输出。核对时重点看“发起请求 / 返回响应”怎样进入对象以及“说明处理结果以及返回什么”怎样证明本次处理已经结束。若两段之间的连续关系无法解释“Client 与 Server 是事务角色不是设备的永久身份。”就不能把局部代码截图当成实现证据。片段一入口、声明与前置条件TYPE ST_HttpRequest : STRUCT eMethod : E_HttpMethod : E_HttpMethod.iUnknown; sMethod : STRING(16) : ; sTarget : STRING(GVL_Http.cnMaxTargetLen) : ; sVersion : STRING(16) : HTTP/1.1; sHost : STRING(GVL_Http.cnMaxHostLen) : ; sContentType : STRING(96) : ; sAuthorization : STRING(160) : ;这一段先回答对象在什么输入和状态下开始工作。阅读时要核对变量的初值、长度上限和启动条件不能只看某个布尔量是否变成 TRUE。片段二状态推进、边界与输出sAdditionalHeader : STRING(GVL_Http.cnMaxHeaderSize) : ; sRawHeaders : STRING(GVL_Http.cnMaxHeaderSize) : ; sBody : STRING(GVL_Http.cnMaxBodySize) : ; bHasContentLength : BOOL : FALSE; bTransferChunked : BOOL : FALSE; bConnectionClose : BOOL : FALSE; udiContentLength : UDINT : 0; END_STRUCT END_TYPE第二段继续展示同一连续源码范围。把它与第一段合起来才能判断输入怎样被锁存、状态何时推进、边界何时满足以及错误出口是否保留了足够诊断信息。验证路径场景操作通过口径读取资源手写 GET/api/status能指出方法、目标、Host 和空行写入内容手写带 JSON Body 的 POSTContent-Type 与 Content-Length 正确解释响应区分 200、400、404、500不再把状态码当 TCP 状态角色判断分别描述 PLC 主动访问与被访问能正确判断 Client 和 Server场景 1读取资源执行“手写 GET/api/status”前先清理上一笔事务的完成脉冲、错误锁存和接收残留再记录起始状态与计数。操作后同时观察外部报文、角色状态机和诊断量只有三条证据共同指向“能指出方法、目标、Host 和空行”这一场景才算通过。若只看到外部结果而内部状态未收口应继续检查资源回收若内部 Done 已出现而报文不完整应回到消息边界重新取证。场景 2写入内容执行“手写带 JSON Body 的 POST”前先清理上一笔事务的完成脉冲、错误锁存和接收残留再记录起始状态与计数。操作后同时观察外部报文、角色状态机和诊断量只有三条证据共同指向“Content-Type 与 Content-Length 正确”这一场景才算通过。若只看到外部结果而内部状态未收口应继续检查资源回收若内部 Done 已出现而报文不完整应回到消息边界重新取证。场景 3解释响应执行“区分 200、400、404、500”前先清理上一笔事务的完成脉冲、错误锁存和接收残留再记录起始状态与计数。操作后同时观察外部报文、角色状态机和诊断量只有三条证据共同指向“不再把状态码当 TCP 状态”这一场景才算通过。若只看到外部结果而内部状态未收口应继续检查资源回收若内部 Done 已出现而报文不完整应回到消息边界重新取证。场景 4角色判断执行“分别描述 PLC 主动访问与被访问”前先清理上一笔事务的完成脉冲、错误锁存和接收残留再记录起始状态与计数。操作后同时观察外部报文、角色状态机和诊断量只有三条证据共同指向“能正确判断 Client 和 Server”这一场景才算通过。若只看到外部结果而内部状态未收口应继续检查资源回收若内部 Done 已出现而报文不完整应回到消息边界重新取证。常见误判把 HTTP 说成一种传输方式没有说明它组织的是请求和响应。把 Client 和 Server 当成设备类型而不是一笔事务中的角色。背出 GET 和 200却说不清资源、Header、Body 和状态码怎样组成完整消息。这些误判的共同点是拿一个局部现象替代完整事务。定位时必须回到本篇的输入、状态、边界和输出四个坐标并用相同输入完成回归。这一篇你最该记住HTTP 管理请求与响应不直接管理 PLC 变量。URL、方法、状态码、Header 和 Body 各有职责。Client 与 Server 是事务角色不是设备的永久身份。系列导航系列CodeSys HTTP 系列教程第 01/28 篇。阶段基础认知职责线位置 1/4。上一篇无这是系列第一篇。下一篇第02篇发布顺序基础认知 - Server - Client - 完整源码加更 - 综合收束。