Windows窗口置顶：WS_EX_TOPMOST与AutoHotkey实现
2026/9/30 3:28:28
在做服务器硬件管理、带外运维或者基础设施自动化的朋友，应该都听过Redfish这个名字。但真到了上手阶段，很多人不是被Redfish本身的接口复杂到劝退，而是被前置知识卡住：RESTful API的规范到底怎么理解，JSON的响应体又该怎么读怎么解析。Redfish这套接口标准，本质上就是“跑在HTTP上的RESTful API”，所有交互报文都用JSON承载。所以我把这篇定位成Redfish前置学习，把RESTful API和JSON这两块地基彻底讲明白，再配合一套能直接照着敲的实操流程，让你在碰真正的Redfish设备之前，先把底层逻辑吃透。
这篇内容适合谁？准备做BMC带外管理脚本的运维工程师、刚接触数据中心硬件自动化的开发，以及那些已经在读Redfish官方文档但被POST /redfish/v1/Systems/{id}/Actions/ComputerSystem.Reset之类接口绕晕的人。看完你会清楚：Redfish为什么选REST，URI和JSON字段该怎么对应，以及遇到解析报错时怎么从HTTP和JSON两个层面去排查。
1. Redfish为什么偏偏选了REST和JSON：先把“新管理协议”的账算清楚
1.1 从IPMI到Redfish：管理接口面临的代际问题
在Redfish出来之前，服务器带外管理事实上的标准是IPMI。IPMI本身不是不能干活，它的问题是命令式协议，走的是RMCP/UDP这种底层通道，发送的是二进制命令。你给服务器发一条“读取CPU温度”的指令，服务器返回一串字节码，要读懂得靠专门的工具或者驱动。这种设计在单机维护时代够用，但放到云数据中心里就非常别扭：你没法用常见的HTTP客户端去调，也没法把管理数据和公司的监控平台直接打通，更别提在脚本里优雅地处理返回结果。
还有一点很致命，IPMI对网络模型的依赖太重，跨三层网络、穿防火墙都要专门配置。现在的数据中心管理越来越强调自动化、可编程、可观测，运维体系里到处是RESTful API和JSON数据交换，IPMI那套字节流协议就像老式电话交换机，功能还在，但已经跟不上现代IT的调度方式。
DMTF组织推出Redfish的时候，思路很明确：干脆把管理协议做成“现代Web应用的样子”。你可以把Redfish理解成一套专门给服务器硬件用的HTTP接口规范，数据表示用JSON，资源组织用URI，操作方式遵循RESTful风格。于是，浏览器插件、curl脚本、Python脚本，甚至Prometheus的exporter，都能直接跟BMC对话。
1.2 REST和JSON在Redfish里到底承担了什么角色
REST（Representational State Transfer）不是一个具体的软件，而是一组架构约束。它要求你把业务能力抽象成“资源”，用HTTP方法去表达对资源的操作，并且通信状态通过标准的状态码来传递。Redfish就是严格按这套思想设计的：服务器是资源，电源是资源，散热风扇是资源，固件版本也是资源。你要做的是对这些资源进行读、改、删、执行操作，而不是像传统API那样发一堆“命令动词”。
JSON在这里的作用更直接。Redfish的每个响应都是一个JSON文档，里面包括资源属性、链接关系、状态信息等。比如你GET一个系统资源，返回的Body就是一段JSON，里面有Status里包含State和Health，有Boot对象描述启动配置，有Links指向关联的其他资源。你看，整个管理界面从“命令+字节流”变成了“资源+结构化文本”，人可读，程序也好解析。
做个粗略对比，你就能感受到差别：
| 维度 | IPMI | Redfish |
|---|---|---|
| 传输方式 | RMCP/UDP二进制命令 | HTTP/HTTPS |
| 数据格式 | 字节流，需专门解码 | JSON，文本直接可读 |
| 调用方式 | 专用命令工具 | 任何HTTP客户端，curl都行 |
| 扩展性 | 厂商私有命令多，难统一 | 标准资源模型+OData扩展 |
| 自动化友好度 | 很低 | 很高，天生配合Ansible、Python |
所以Redfish选REST和JSON，不是拍脑袋，而是管理协议从“设备时代”进入“软件时代”的必然结果。
2. RESTful API的三个核心概念，对照Redfish具体接口理解
2.1 资源和URI：Redfish的地址不是“命令”，是“物品”
RESTful API里最重要的思维转变是：你面对的不再是一堆函数，而是一堆“东西”。Redfish里的每个“东西”都有唯一地址，也就是URI。比如：
https://bmc-ip/redfish/v1/是Redfish服务的入口https://bmc-ip/redfish/v1/Systems/是服务器系统的集合https://bmc-ip/redfish/v1/Systems/437XR1138R2/是某台具体的服务器/redfish/v1/Chassis/1U/是机箱资源/redfish/v1/Managers/BMC/是BMC自身的管理资源
注意这里的命名风格，路径里全是名词，没有动词。你不会看到GetSystemStatus这种地址，只会看到Systems/{id}这样的资源路径。这个设计看似简单，实际影响很大：因为资源是嵌套的，你顺着一个链接就能发现其他相关资源。
在Redfish的JSON响应里，几乎每个对象都会带一个@odata.id字段，它的值就是该资源的URI。这就是REST里HATEOAS思想的体现——服务器在返回数据的同时告诉你“这个资源的相关入口在哪里”。我见过不少新手拿着文档里的URI硬记，其实根本不用背，你只要GET一次资源，看它返回的Links和@odata.id，整个资源地图就出来了。
2.2 四个动词：GET读、POST建、PATCH改、DELETE删
RESTful API对资源的操作，靠HTTP方法（也叫动词）。Redfish用得最多的也就四个：
GET：读取资源。不改变状态，是幂等的，随时可以反复调用。POST：创建资源，或者触发一个动作。Redfish里很多动作都挂在POST上，比如重启、开关机、更新固件。PATCH：局部更新资源。只改你传上去的字段，其他字段不动。Redfish里调整启动顺序、修改资产信息，基本都是PATCH。DELETE：删除资源。Redfish里偶尔用到，比如删除虚拟介质挂载、删除Session。
PUT很少见，因为PUT是整量替换，动不动就把整个对象覆盖掉，对硬件管理来说风险太大。Redfish官方设计也刻意回避了PUT，更推荐PATCH这种增量式修改。这点你在调接口时要注意，别想着一口气PUT整个服务器配置上去，大概率会被拒绝或者引发副作用。
举个例子，如果你想设置某台服务器下一次从PXE启动：
curl -k -X PATCH https://bmc-ip/redfish/v1/Systems/437XR1138R2/ \ -H "Content-Type: application/json" \ -d '{"Boot":{"BootSourceOverrideTarget":"Pxe","BootSourceOverrideEnabled":"Once"}}'这里就是把Boot这个嵌套对象里的两个字段改掉，其他启动配置原样保留。这种“只动局部”的方式，正是PATCH在Redfish里被广泛使用的理由。
2.3 状态码与统一错误体：Redfish告诉你“错在哪一层”
RESTful API必然依赖HTTP状态码来表达结果，Redfish也不例外。你基本会遇到这些：
200 OK：GET成功，或者POST动作执行成功。201 Created：资源创建成功，比如创建了Session。204 No Content：操作成功但没有返回体，比如某些DELETE。400 Bad Request：请求格式有问题，多半是JSON语法错或者字段值不合法。401 Unauthorized：没认证，token丢了或者账号密码错。403 Forbidden：认证通过但没权限。404 Not Found：URI不存在，或者资源ID写错。405 Method Not Allowed：方法用错，比如把POST用在了只支持GET的资源上。500 Internal Server Error：BMC内部处理出错。
Redfish还规定了统一的错误响应结构。一个典型的错误体长这样：
{ "error": { "code": "Base.1.8.ResourceNotFound", "message": "The requested resource was not found.", "@Message.ExtendedInfo": [ { "@odata.type": "#Message.v1_1_2.Message", "MessageId": "Base.1.8.ResourceNotFound", "Message": "The requested resource was not found.", "Resolution": "Check the URI and try again." } ] } }很多人第一次看到code字段里的Base.1.8.ResourceNotFound会觉得奇怪，这不是随便起的名字，它是Redfish消息注册表里定义的标准化消息ID。Base是消息注册表名，1.8是版本，ResourceNotFound是具体消息名。拿到这个code，你就能去官方消息注册表里查标准含义，而不是盯着厂商翻译过度的中文提示猜。实际排查中，状态码决定排查方向，code决定具体原因，两者配合用，能少走很多弯路。
3. JSON基础补课：读懂Redfish响应之前必须避开的坑
3.1 JSON的6种数据类型与Redfish常见组合
JSON的数据类型不多，就六种：对象（{}）、数组（[]）、字符串（"..."）、数字（123、1.5）、布尔值（true/false）、空值（null）。Redfish的响应基本就是这几个类型的排列组合。
给你看一个Redfish里常见的系统资源片段：
{ "@odata.id": "/redfish/v1/Systems/437XR1138R2/", "@odata.type": "#ComputerSystem.v1_16_0.ComputerSystem", "Id": "437XR1138R2", "Name": "Web Front End Node", "SystemType": "Physical", "AssetTag": "Chicago-1A", "Manufacturer": "Contoso", "Model": "3500RX", "SerialNumber": "437XR1138R2", "MemorySummary": { "TotalSystemMemoryGiB": 64, "Status": { "State": "Enabled", "Health": "OK" } }, "Boot": { "BootSourceOverrideTarget": "None", "BootSourceOverrideMode": "UEFI" }, "Links": { "Chassis": [ { "@odata.id": "/redfish/v1/Chassis/1U/" } ], "ManagedBy": [ { "@odata.id": "/redfish/v1/Managers/BMC/" } ] } }你看，MemorySummary是对象，里面的Status又是嵌套对象；Links里的Chassis是数组，数组元素又是对象。这种复合结构在Redfish里太普遍了，所以解析JSON不能只看一层，要习惯“点路径”式地往下走，比如data["MemorySummary"]["Status"]["State"]。
3.2 数组与对象：定位一个硬盘、一条日志的方法
很多人解析JSON容易把数组和对象搞混，在Redfish场景里这个错误代价很大。拿存储来说，你GET/redfish/v1/Systems/{id}/Storage/，返回的通常是：
{ "@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/", "Members": [ { "@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/SATA-1/" }, { "@odata.id": "/redfish/v1/Systems/437XR1138R2/Storage/NVMe-1/" } ], "Members@odata.count": 2 }Members就是数组，它表示“集合下的成员列表”。你要遍历所有存储控制器，就得用循环：
storage_members = data.get("Members", []) for member in storage_members: storage_uri = member["@odata.id"] print(storage_uri)注意Members@odata.count这个字段，它告诉你集合里有多少成员。这是Redfish里OData分页约定的体现，当你资源数量多时，响应可能不会返回全部成员，而是分页返回，你要靠这个字段判断是不是还有下一页。不少人写脚本死盯着第一页数据，结果漏掉了一半服务器，原因就是没处理Members@odata.count和NextLink。
日志场景也一样。你GET日志服务集合，返回的Entries字段是数组，数组每个元素是一条日志。凡是看到字段名带复数、值以[开头的，基本就是数组，必须用索引或循环访问，不能直接点属性名。这条规律在不同厂商的Redfish实现里都通用。
3.3 “JSON没毛病，代码报错”的典型场景：强类型反序列化
JSON本身很宽容，但很多编程语言是强类型的，把JSON“翻译”成对象的时候就会爆发各种奇葩报错。拿热搜里常见的java.util.Date反序列化错误来说，典型提示是：
JSON parse error: Cannot deserialize value of type `java.util.Date` from String "2024-08-21T10:00:00Z": not a valid representation这个错不怪JSON，JSON字符串"2024-08-21T10:00:00Z"本身挺标准，是某个实现没告诉Jackson怎么把这个字符串转成java.util.Date。解决方案通常是在Java类上加上@JsonFormat注解：
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss'Z'", timezone = "UTC") private Date timestamp;这种问题在Redfish里特别常见，因为Redfish大量使用带时区的UTC时间字符串，比如"2024-08-21T10:00:00Z"、"2024-08-21T10:00:00+08:00"。你用Java SDK解析Redfish时间字段，十有八九会遇到日期格式不对的问题。学到这一课，以后再看到反序列化报错，先别怀疑响应体，先去看你代码里的类型定义跟JSON字段对不对得上。
我做了一个表格，把Redfish场景下最常碰到的几类解析问题列出来：
| 报错方向 | 常见原因 | 排查顺序 |
|---|---|---|
| 无法反序列化字符串为Date | JSON时间格式与语言默认格式不匹配 | 先看原始JSON值，再检查时间解析格式 |
| 期望对象但得到数组 | 字段名理解错，比如把Members当对象 | 打印响应体，看实际是什么结构 |
| 键名不存在 | 不同厂商Redfish实现字段有差异 | 用jq或Python的keys()先看所有键 |
| 嵌套过深无法自动映射 | 响应结构里有Links这类递归引用 | 自己写解析，不要全指望自动映射 |
| 中文乱码 | 响应体编码不匹配 | 确保HTTP客户端按UTF-8解码 |
4. 实操：用curl与一台“假Redfish”对话，把整套流程跑通
4.1 没有真机怎么办：用mockup仿真器搭一套练习环境
学Redfish最大的阻碍是没设备。升级一次固件要审批，重启一台服务器可能影响业务，谁也不敢在真机上乱试。好在Redfish有一套官方mockup，也就是标准示例数据，配合DMTF提供的mockup服务器脚本，可以在本机跑一个仿真的Redfish服务。
做法很简单，先找一个Redfish mockup数据包，再用Python的redfish-mockup-server脚本把它服务化。大致步骤是：
# 下载mockup数据后，进入目录 python3 redfish-mockup-server.py -host 0.0.0.0 -port 8000 /path/to/mockup/folder然后本机就多了一个跑在8000端口的Redfish服务，随你怎么折腾。没有图形界面的服务器环境也行，只要Python3能跑起来就行。这里有个细节要留意：mockup服务器默认是只读的，你执行PATCH操作它会返回“操作不允许”，但它依然会完整展示RESTful API的资源和结构。练手的目标本来就不是改真实状态，而是熟悉URI、响应体、认证流程，这点足够了。
如果你有真实的BMC环境，那就更方便，直接用BMC的IP地址替换即可。但建议第一步还是在mockup上做，至少你可以放心地把每个接口都GET一遍，看真实的JSON长什么样。
4.2 认证那条路：Basic Auth与Session Token都要会
Redfish的认证有两种常见形态，手动调接口时你最好两种都掌握。
第一种是Basic Auth，就是HTTP自带的用户名密码认证：
curl -k -u admin:password https://bmc-ip/redfish/v1/Systems/-k是忽略证书校验，因为BMC的HTTPS证书通常是自签名的。-u把账号密码塞进请求头。这种方式简单直接，但每次请求都要携带凭据，安全性不如Session。
第二种是创建Session，先认证一次，拿到token，后续请求用token：
# 1. 创建Session，返回的Header里有X-Auth-Token curl -k -i -X POST https://bmc-ip/redfish/v1/SessionService/Sessions \ -H "Content-Type: application/json" \ -d '{"UserName":"admin","Password":"password"}'注意这里我加了-i，目的是查看响应头。因为X-Auth-Token不在响应Body里，而在Header里。你用-i会看到类似：
HTTP/1.1 201 Created Location: /redfish/v1/SessionService/Sessions/12345/ X-Auth-Token: abcdef0123456789把token复制出来，后面的请求都用它：
curl -k -H "X-Auth-Token: abcdef0123456789" \ https://bmc-ip/redfish/v1/Systems/Session的好处是，用完可以DELETE掉这个Session资源，主动让token失效，比长期裸奔的Basic Auth安全。练习阶段两个都要跑一遍，因为不同厂商BMC对认证的支持差别还挺大，有的默认关闭Session服务，有的只允许Basic。会两套方案，你到任何环境都不慌。
4.3 三个高频操作：查系统、改启动项、发重置命令
在仿真环境跑通认证后，我建议你依次做三个高频操作，这三个操作几乎覆盖了Redfish日常使用的七成场景。
操作一：查看系统列表和关键信息
curl -k -H "X-Auth-Token: $TOKEN" \ https://bmc-ip/redfish/v1/Systems/拿到返回的JSON后，先别急着写脚本，用Python或者jq格式化一下，把Members数组里的@odata.id都列出来。然后选一个系统ID，再GET详情：
curl -k -H "X-Auth-Token: $TOKEN" \ https://bmc-ip/redfish/v1/Systems/437XR1138R2/重点关注PowerState（当前电源状态）、Status（健康状态）、MemorySummary（内存信息）、ProcessorSummary（CPU信息）这几个字段。这些是巡检脚本里会出现频率最高的属性。
操作二：设置一次性PXE启动
curl -k -X PATCH https://bmc-ip/redfish/v1/Systems/437XR1138R2/ \ -H "Content-Type: application/json" \ -H "X-Auth-Token: $TOKEN" \ -d '{"Boot":{"BootSourceOverrideTarget":"Pxe","BootSourceOverrideEnabled":"Once"}}'这里的“Once”很关键，它表示只在下一次开机时覆盖启动源，之后再恢复正常启动顺序。这比直接改默认启动顺序安全得多，免得服务器以后每次开机都去网卡找PXE，半天起不来系统。
操作三：远程重启服务器
curl -k -X POST https://bmc-ip/redfish/v1/Systems/437XR1138R2/Actions/ComputerSystem.Reset \ -H "Content-Type: application/json" \ -H "X-Auth-Token: $TOKEN" \ -d '{"ResetType":"ForceRestart"}'ComputerSystem.Reset是Redfish标准动作，路径固定跟在系统资源的Actions下面。ResetType支持的值很多，像On、ForceOff、GracefulRestart、ForceRestart、Nmi，不同BMC实现支持的范围不太一样，可以先OPTIONS一下看看允许哪些值。很多厂商文档不会逐字列全，但你可以通过GET系统资源的Actions字段看到这个系统具体支持哪些ResetType。
这三个操作跑一遍，你对“资源+HTTP方法+JSON请求体”这套Redfish交互模式就有手感了。
5. 用Python写第一个Redfish巡检脚本（附关键细节）
5.1 为什么学习阶段不建议直接上官方SDK
一搜Redfish Python，很容易找到官方提供的redfish库，封装了session、请求、解析等一堆东西。我的建议是：学习阶段先别急着用它，直接拿requests写。
理由很简单，官方SDK帮你隐藏了太多细节。你不知道token怎么传的，不知道请求超时怎么处理的，不知道返回数据在哪个对象里。一旦到了某些厂商BMC实现有差异的环境，SDK报错你会完全无从排查。先用requests裸写一遍，你会深刻理解认证头、超时、状态码、JSON解析这些基本功，以后再上SDK，就能看懂它在干什么。
5.2 封装请求、处理分页和缺失键
一个基础巡检脚本大致长这样：
import requests import json BMC_IP = "192.168.1.100" USERNAME = "admin" PASSWORD = "password" BASE_URL = f"https://{BMC_IP}/redfish/v1" s = requests.Session() s.auth = (USERNAME, PASSWORD) s.verify = False # 忽略自签名证书 def get_resource(path): url = f"{BASE_URL}/{path}" resp = s.get(url, timeout=10) resp.raise_for_status() return resp.json() # 获取系统列表 data = get_resource("Systems/") for member in data.get("Members", []): system_uri = member["@odata.id"] # 去掉前缀，直接用相对路径 relative = system_uri.replace(BASE_URL, "").strip("/") detail = get_resource(relative) print(json.dumps({ "id": detail.get("Id"), "power_state": detail.get("PowerState"), "health": detail.get("Status", {}).get("Health"), }, indent=2))这里有几个关键细节我特别提醒一下。
第一，s.verify = False在真实生产环境别这么写，但练习阶段不关掉，你大概率会被自签名证书卡死。更规范的做法是用verify="/path/to/ca.pem"指定CA证书。
第二，timeout=10必须加。BMC有些操作响应很慢，不加超时，脚本会无限卡住，尤其是批量巡检几十台机器时，一台不响应就拖垮整个任务。
第三，取嵌套字段务必用.get("key", {})的链式写法，不要直接detail["Status"]["Health"]。因为不同厂商的BMC可能不返回Status，或者Status是空的，一旦键不存在，你的巡检任务就中断了。用get加默认值，脚本的容错性会好很多。
5.3 对“看起来正常但运行报错”的三个排查顺序
写Redfish脚本最气人的一种情况是：curl一敲就出数据，Python脚本一跑就报错，看起来无比诡异。我的排查顺序永远是这三步。
第一步，打印原始响应文本。很多人在resp.json()这一步抛异常，不代表服务端返回的不是JSON，而是响应里混入了非JSON内容。比如登录失败的页面返回的是HTML，或者网络设备在JSON前面加了个BOM头。先print(resp.text)看真实内容，比自己瞎猜强百倍。
第二步，检查请求头。Redfish很多接口要求Content-Type: application/json，很多接口对Accept头也有要求。你用curl时可能带了某些默认头，脚本里没注意就漏了，服务端行为会完全不同。把Python的请求头跟curl的-v输出对比，基本能找到差异。
第三步，单独验证响应里的某个字段。如果数据能解析但字段拿不到，就用Python交互环境或者jq手动检查这个结构的真实键名。我之前就遇到过厂商把MemorySummary改成了Memory的兼容实现，文档没更新，导致脚本读出None。这种事在Redfish生态里不少见，所以写解析逻辑前，先用脚本把待解析的JSON打得漂漂亮亮，看清键名再动手。
6. 从热搜问题看JSON实战中最容易卡住的三类场景
6.1 格式化、校验与转换：工具怎么用才不至于帮倒忙
网上搜JSON，跳出来的高频问题一大半是关于格式化、校验、转换的。Redfish场景里，格式化工具确实有用，尤其是响应数据一长串压成一行时，不格式化根本没法看。我习惯的做法是把响应体存成resp.json文件，然后在命令行用jq处理：
curl -k -H "X-Auth-Token: $TOKEN" \ https://bmc-ip/redfish/v1/Systems/437XR1138R2/ -o system.json jq . system.jsonjq .就是漂亮的格式化输出。如果你想提取某个字段，直接写路径：
jq '.Status.Health' system.json至于在线格式化工具，也不是不能用，但注意别把真实BMC的敏感信息贴进去。我见过有人图省事把带SerialNumber和MAC地址的Redfish响应贴到公开网页上，这在企业环境是妥妥的信息泄露风险。本地用jq或者VS Code插件，效果一样，还能保住隐私。
关于JSON转CSV、转Excel这类需求，Redfish场景其实不太建议做通用转换。因为Redfish嵌套结构太多，展平后字段含义容易丢失。真要导数据做报表，我建议按需自己写Python脚本，明确选择要导出的字段，而不是指望一个万能转换器。
6.2 JSON对象和JSON数组被搞混时的定位方法
你看热搜里有不少“json数组”“json对象”的疑问，Redfish里这个坑尤其高频。简单判断方法就三条：
- 以
{开头，是对象，表示一个实体的属性集合。 - 以
[开头，是数组，表示一组实体。 - 数组中每个元素可以是对象，Redfish里最常见的就是
Members数组，里面每个元素都有@odata.id。
很多人写解析代码时报“对象不能用下标遍历”，基本就是把数组当对象用了。我的习惯是，第一次解析一个从未见过的Redfish资源前，先用type()或者jq type确认顶层结构：
data = resp.json() print(type(data)) # <class 'dict'> 或 <class 'list'> print(type(data["Members"])) # 一定是 list这种确认看起来多此一举，但能省下大量瞎试的时间。尤其是你对接的厂商BMC版本比较旧，字段结构跟最新标准不一致，一上来就硬写解析代码，报错之后还要回头猜结构，效率极差。先确认结构，再写路径，是JSON解析的黄金法则。
6.3 不同语言处理JSON的脾气差异：Python、Java、Shell
最后说说不同语言对JSON的“脾气”，这也是热搜里跨语言JSON问题特别多的原因。
Python的json模块把JSON转成字典和列表，跟JavaScript一样天然贴合。你只需要注意true和false会变成Python的True和False，JSON里的null会变成None，别在代码里直接比较字符串就行。
Java相对麻烦。你拿到的是JsonObject、JsonArray，或者是项目里定义的POJO配合Jackson、Gson反序列化。Java的强类型要求每个字段都有对应的类定义，JSON里多一个字段或者少一个字段，或者日期格式不对，反序列化就可能炸。解决思路是灵活使用JsonNode这类树模型，树模型可以避免为每个接口都写一大堆类，适合Redfish这种结构经常轻微变化的场景。
Shell这边，我强烈建议用jq而不是用grep和sed去抠JSON。jq是专门为JSON设计的，支持条件、管道、切片，比如：
jq -r '.Members[] | .["@odata.id"]' system.json这行命令会输出所有成员的URI。如果用grep去抠，遇到字符串里恰好包含@odata.id的干扰项就会出错。Redfish场景里，短平快的运维脚本用jq，复杂巡检任务用Python，这个分工我一直觉得最顺手。
写Redfish脚本做得多了，我自己最大的体会是：这个领域90%的问题都出在“没有把RESTful API和JSON这两层基础当真”。很多人一上来就背接口、套SDK，遇到响应结构变化就蒙。其实只要把资源、URI、状态码、JSON嵌套结构这四件事搞清楚，再配合curl和Python反复试，Redfish的学习曲线会平滑很多。如果你非要从一个动作开始练，我建议先把mockup环境跑起来，从一次GET请求开始，然后逐步加认证、加PATCH、加动作调用，一步步把REST和JSON的感觉建立起来，后面看任何厂商的Redfish文档都会轻松得多。