Redfish — Trivia & Interesting Facts¶
Surprising, historical, and little-known facts about the Redfish standard for hardware management.
Redfish was created because IPMI's security was fundamentally unfixable¶
The DMTF (Distributed Management Task Force) developed Redfish starting in 2014 as a direct replacement for IPMI, which had well-documented security vulnerabilities baked into its protocol design. Rather than trying to patch IPMI, the industry decided to start over with a modern RESTful API using HTTPS, JSON, and OData conventions. The first Redfish specification (1.0) was published in August 2015.
The name "Redfish" has no deep meaning — it was just a catchy project codename¶
Unlike many tech standards with meaningful acronyms, "Redfish" was simply the internal codename used during development at the DMTF, and it stuck. The standard's official name is "Redfish Scalable Platforms Management API," but everyone just calls it Redfish. The logo features a stylized red fish, leaning into the branding.
Redfish uses JSON and REST, making it the first BMC API that web developers can understand¶
IPMI's binary protocol and SNMP's MIB/OID structure were opaque to anyone without specialized knowledge. Redfish deliberately chose JSON over REST/HTTPS — technologies that every web developer already knows. A curl command to https://bmc-ip/redfish/v1/Systems/1 returns human-readable JSON describing the server. This design decision dramatically lowered the barrier to hardware automation.
Dell, HP, Lenovo, and Supermicro all ship Redfish on current-generation servers¶
Every major server vendor now ships Redfish support in their BMC firmware. Dell's iDRAC9 (14th gen onward), HPE's iLO 5+, Lenovo's XClarity Controller, and Supermicro's BMC all support Redfish. However, the depth of implementation varies significantly — some vendors support hundreds of Redfish endpoints while others implement only the basics. This inconsistency is Redfish's biggest practical challenge.
Redfish's OData foundation means it supports query filtering and pagination natively¶
Redfish adopted OData (Open Data Protocol) conventions, which means clients can filter collections (?$filter=Status/Health eq 'OK'), expand nested resources (?$expand=Members), and paginate large result sets. These features are essential for fleet management at scale — querying 10,000 BMCs for all servers with degraded health becomes a simple API call rather than a custom script.
The Swordfish extension adds storage management to Redfish¶
SNIA (Storage Networking Industry Association) created Swordfish as a Redfish-based standard for storage management. Swordfish extends Redfish's data model to cover storage arrays, volumes, pools, and storage services. The goal is to manage compute and storage through a single, consistent API — ending the era of separate management interfaces for servers and storage arrays.
OpenBMC implements Redfish on open-source BMC firmware¶
OpenBMC, the open-source BMC firmware project started by Facebook in 2014 and now hosted by the Linux Foundation, uses Redfish as its management API. The bmcweb project provides the Redfish implementation for OpenBMC. This combination gives hyperscalers like Facebook/Meta, Google, and Microsoft full control over both the firmware and the management API on their custom server hardware.
Redfish event subscriptions enable push-based monitoring for the first time¶
Unlike IPMI, which requires polling for sensor data, Redfish supports Server-Sent Events (SSE) and webhook-based event subscriptions. A monitoring system can register for specific events (temperature threshold, drive failure, power supply fault) and receive push notifications in real time. This reduces BMC network traffic and provides faster alerting compared to periodic IPMI sensor polling.
Redfish Composability enables disaggregated hardware management¶
Redfish's Composability specification (added in later versions) supports managing disaggregated hardware — servers where CPU, memory, storage, and network components can be independently allocated and reconfigured. While disaggregated hardware is still emerging, the API specification is already in place. This forward-looking design means Redfish won't need to be replaced when hardware architectures evolve.
Adoption of Redfish is slower than expected because IPMI "works well enough"¶
Despite Redfish's technical superiority, many organizations still use ipmitool for day-to-day BMC operations because it's simple, well-known, and already integrated into their tooling. Migrating from IPMI to Redfish requires updating monitoring scripts, provisioning tools, and operational procedures — effort that's hard to justify when the existing IPMI setup works. This "good enough" inertia is Redfish's biggest adoption barrier.