ISO/IEC 30115:2018

Information technology - Redfish scalable platforms management API specification

ISO/IEC 30115:2018: The Redfish Scalable Platforms Management API ("Redfish") is a new specification that uses RESTful interface semantics to access data defined in model format to perform out-of-band systems management. It is suitable for a wide range of servers, from stand-alone servers to rack mount and bladed environments but scales equally well for large scale cloud environments. There are several out-of-band systems management standards (defacto and de jour) available in the industry. They all either vary widely in implementation, were developed for single server embedded environments or have their roots in antiquated software modeling constructs. There is no single industry standard that is simple to use, based on emerging programming standards, embedded friendly and capable of meeting large scale data center & cloud needs.

Technologies de l'information — Spécification API (interface de programmation d'applications) relative à la gestion des plates-formes évolutives Redfish

General Information

• Status: Withdrawn
• Publication Date: 09-Apr-2018
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 01-Sep-2022
• Completion Date: 30-Oct-2025

Relations

• Replaced By: ISO/IEC 30115-2:2022 - Information technology - Redfish scalable platforms management API specification - Part 2: Redfish Schema Supplement v2021.1
• Effective Date: 26-Nov-2021
• Revised: ISO/IEC 30115-1:2022 - Information technology - Redfish scalable platforms management API specification - Part 1: Redfish Specification v1.13.0
• Effective Date: 26-Nov-2021

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 30115
First edition
2018-03
Information technology — Redfish
scalable platforms management API
specification
Technologies de l'information — Spécification API (interface de
programmation d'applications) relative à la gestion des plates-formes
évolutives Redfish
Reference number
©
ISO/IEC 2018
© ISO/IEC 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
Published in Switzerland
ii © ISO/IEC 2018 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non‐governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.s
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of document should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by the Distributed Management Task Force, Inc. (DMTF) (as DSP0266) and
drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology.
© ISO/IEC 2018 – All rights reserved iii

DSP0266 Redfish Scalable Platforms Management API Specification
CONTENTS
1. Abstract . 8
2. Normative references . 8
3. Terms and definitions . 9
4. Symbols and abbreviated terms . 12
5. Overview . 12
5.1. Scope . 13
5.2. Goals . 13
5.3. Design tenets . 14
5.4. Limitations . 14
5.5. Additional design background and rationale. 15
5.5.1. REST-based . 15
5.5.2. Follow OData conventions . 15
5.5.3. Model-oriented . 16
5.5.4. Separation of protocol from data model . 16
5.5.5. Hypermedia API service endpoint . 16
5.6. Service elements . 16
5.6.1. Synchronous and asynchronous operation support. 16
5.6.2. Eventing mechanism . 17
5.6.3. Actions. 17
5.6.4. Service entry point discovery . 17
5.6.5. Remote access support . 18
5.7. Security . 18
6. Protocol details . 18
6.1. Use of HTTP . 19
6.1.1. URIs . 19
6.1.2. HTTP methods . 20
6.1.3. HTTP redirect . 21
6.1.4. Media types . 21
6.1.5. ETags . 21
6.2. Protocol version . 22
6.3. Redfish-defined URIs and relative URI rules . 23
6.4. Requests . 24
6.4.1. Request headers . 24
6.4.2. Read requests (GET) . 26
6.4.3. HEAD . 28
6.4.4. Data modification requests . 29
6.5. Responses . 32
6.5.1. Response headers . 33
6.5.2. Status codes . 35
6.5.3. Metadata responses . 38
6.5.4. Resource responses . 41
Version 1.2.0 Published 3
iv © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
6.5.5. Resource Collection responses . 49
6.5.6. Error responses . 50
7. Data model and Schema . 53
7.1. Schema repository . 53
7.1.1. Programmatic access to schema files . 53
7.2. Type identifiers . 54
7.2.1. Type identifiers in JSON . 54
7.3. Common naming conventions . 54
7.4. Localization considerations . 55
7.5. Schema definition . 55
7.5.1. Common annotations . 55
7.5.2. Schema documents . 56
7.5.3. Resource type definitions . 58
7.5.4. Resource properties . 58
7.5.5. Reference properties . 62
7.5.6. Resource actions . 64
7.5.7. Resource extensibility . 65
7.5.8. Oem property examples . 67
7.6. Common Redfish resource properties . 69
7.6.1. Id . 69
7.6.2. Name . 69
7.6.3. Description . 55
7.6.4. Status . 70
7.6.5. Links . 70
7.6.6. Members . 70
7.6.7. RelatedItem . 70
7.6.8. Actions. 17
7.6.9. OEM . 70
7.7. Redfish resources . 71
7.7.1. Current configuration . 71
7.7.2. Settings . 71
7.7.3. Services . 71
7.7.4. Registry . 72
7.8. Special resource situations . 72
7.8.1. Absent resources . 72
7.8.2. Schema variations . 72
8. Service details . 73
8.1. Eventing . 73
8.1.1. Event message subscription . 74
8.1.2. Event message objects . 74
8.1.3. Subscription cleanup . 75
8.2. Asynchronous operations . 75
8.3. Resource tree stability . 76
4 Published Version 1.2.0
v
© ISO/IEC 2018 – All rights reserved

DSP0266 Redfish Scalable Platforms Management API Specification
8.4. Discovery . 77
8.4.1. UPnP compatibility . 77
8.4.2. USN format. 77
8.4.3. M-SEARCH response . 77
8.4.4. Notify, alive, and shutdown messages . 78
9. Security . 18
9.1. Protocols . 78
9.1.1. TLS . 78
9.1.2. Cipher suites . 78
9.1.3. Certificates . 79
9.2. Authentication . 79
9.2.1. HTTP header security . 79
9.2.2. Extended error handling . 80
9.2.3. HTTP header authentication . 80
9.2.4. Session Management . 80
9.2.5. AccountService . 83
9.2.6. Async tasks . 83
9.2.7. Event subscriptions . 83
9.2.8. Privilege model/Authorization . 83
9.2.9. Redfish Service Operation to Privilege Mapping . 84
10. Redfish Host Interface . 92
11. Redfish Composability . 92
11.1. Composition Requests . 92
11.1.1. Specific Composition . 92
12. ANNEX A (informative) . 93
12.1. Change log . 93
Version 1.2.0 Published 5
vi © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
Foreword
The Redfish Scalable Platforms Management API ("Redfish") was prepared by the Scalable Platforms
Management Forum of the DMTF.
DMTF is a not-for-profit association of industry members dedicated to promoting enterprise and systems
management and interoperability. For information about the DMTF, see http://www.dmtf.org.
6 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved vii

DSP0266 Redfish Scalable Platforms Management API Specification
Acknowledgments
The DMTF acknowledges the following individuals for their contributions to this document:
• Jeff Autor - Hewlett Packard Enterprise
• Patrick Boyd - Dell Inc.
• David Brockhaus - Emerson Network Power
• Richard Brunner - VMware Inc.
• Lee Calcote - Seagate Technology
• P Chandrasekhar - Dell Inc.
• Chris Davenport - Hewlett Packard Enterprise
• Gamma Dean - Emerson Network Power
• Daniel Dufresne - EMC
• Samer El-Haj-Mahmoud - Lenovo, Hewlett Packard Enterprise
• George Ericson - EMC
• Wassim Fayed - Microsoft Corporation
• Mike Garrett - Hewlett Packard Enterprise
• Steve Geffin - Emerson Network Power
• Joe Handzik - Hewlett Packard Enterprise
• Jon Hass - Dell Inc.
• Jeff Hilland - Hewlett Packard Enterprise
• Chris Hoffman - Emerson Network Power
• Steven Krig - Intel Corporation
• John Leung - Intel Corporation
• Jagan Molleti - Dell Inc.
• Milena Natanov - Microsoft Corporation
• Michael Pizzo - Microsoft Corporation
• Chris Poblete - Dell Inc.
• Michael Raineri - EMC
• Irina Salvan - Microsoft Corporation
• Hemal Shah - Broadcom Limited
• Jim Shelton - Emerson Network Power
• Tom Slaight - Intel Corporation
• Donnie Sturgeon - Emerson Network Power
• Pawel Szymanski - Intel Corporation
• Paul Vancil - Dell Inc.
• Linda Wu - Super Micro Computer, Inc.
Version 1.2.0 Published 7
viii © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
1. Abstract
The Redfish Scalable Platforms Management API ("Redfish") is a new specification that uses RESTful
interface semantics to access data defined in model format to perform out-of-band systems management.
It is suitable for a wide range of servers, from stand-alone servers to rack mount and bladed
environments but scales equally well for large scale cloud environments.
There are several out-of-band systems management standards (defacto and de jour) available in the
industry. They all either vary widely in implementation, were developed for single server embedded
environments or have their roots in antiquated software modeling constructs. There is no single industry
standard that is simple to use, based on emerging programming standards, embedded friendly and
capable of meeting large scale data center & cloud needs.
2. Normative references
The following referenced documents are indispensable for the application of this document. For dated or
versioned references, only the edition cited (including any corrigenda or DMTF update versions) applies.
For references without a date or version, the latest published edition of the referenced document
(including any corrigenda or DMTF update versions) applies.
• IETF RFC 3986 T. Berners-Lee et al, Uniform Resource Identifier (URI): Generic Syntax,
http://www.ietf.org/rfc/rfc3986.txt
• IETF RFC 4627, D. Crockford, The application/json Media Type for JavaScript Object Notation
(JSON), http://www.ietf.org/rfc/rfc4627.txt
• IETF RFC 5789, L. Dusseault et al, PATCH method for HTTP, http://www.ietf.org/rfc/rfc5789.txt
• IETF RFC 5280, D. Cooper et al, Web linking, http://www.ietf.org/rfc/rfc5280.txt
• IETF RFC 5988, M. Nottingham, Web linking, http://www.ietf.org/rfc/rfc5988.txt
• IETF RFC 6901, P. Bryan, Ed. et al, JavaScript Object Notation (JSON) Pointer,
http://www.ietf.org/rfc/rfc6901.txt
• IETF RFC 6906, E. Wilde, The 'profile' Link Relation Type, http://www.ietf.org/rfc/rfc6906.txt
• IETF RFC 7230, R. Fielding et al., Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and
Routing, http://www.ietf.org/rfc/rfc7230.txt
• IETF RFC 7231, R. Fielding et al., Hypertext Transfer Protocol (HTTP/1.1): Semantics and
Content, http://www.ietf.org/rfc/rfc7231.txt
• IETF RFC 7232, R. Fielding et al., Hypertext Transfer Protocol (HTTP/1.1): Conditional
Requests, http://www.ietf.org/rfc/rfc7232.txt
• IETF RFC 7234, R. Fielding et al., Hypertext Transfer Protocol (HTTP/1.1): Caching,
http://www.ietf.org/rfc/rfc7234.txt
• IETF RFC 7235, R. Fielding et al., Hypertext Transfer Protocol (HTTP/1.1): Authentication,
http://www.ietf.org/rfc/rfc7235.txt
8 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved 1

DSP0266 Redfish Scalable Platforms Management API Specification
• ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards,
http://isotc.iso.org/livelink/
livelink.exe?func=ll&objId=4230456&objAction=browse&sort=subtypeH
• JSON Schema, Core Definitions and Terminology, Draft 4 http://tools.ietf.org/html/draft-zyp-json-
schema-04.txt
• JSON Schema, Interactive and Non-Interactive Validation, Draft 4 http://tools.ietf.org/html/draft-
fge-json-schema-validation-00.txt
• OData Version 4.0 Part 1: Protocol. 24 February 2014. http://docs.oasis-open.org/odata/odata/
v4.0/os/part1-protocol/odata-v4.0-os-part1-protocol.html
• OData Version 4.0 Part 2: URL Conventions. 24 February 2014. http://docs.oasis-open.org/
odata/odata/v4.0/os/part2-url-conventions/odata-v4.0-os-part2-url-conventions.html
• OData Version 4.0 Part 3: Common Schema Definition Language (CSDL). 24 February 2014.
http://docs.oasis-open.org/odata/odata/v4.0/os/part3-csdl/odata-v4.0-os-part3-csdl.html
• OData Version 4.0: Core Vocabulary. 24 February 2014. http://docs.oasis-open.org/odata/odata/
v4.0/os/vocabularies/Org.OData.Core.V1.xml
• OData Version 4.0 JSON Format. 24 February 2014. http://docs.oasis-open.org/odata/odata-
json-format/v4.0/os/odata-json-format-v4.0-os.html
• OData Version 4.0: Units of Measure Vocabulary. 24 February 2014. http://docs.oasis-open.org/
odata/odata/v4.0/os/vocabularies/Org.OData.Measures.V1.xml
• Simple Service Discovery Protocol/1.0. 28 October 1999. http://tools.ietf.org/html/draft-cai-ssdp-
v1-03
• The Unified Code for Units of Measure. http://www.unitsofmeasure.org/ucum.html
• W3C Recommendation of Cross-Origin Resource Sharing. 16 January 2014. http://www.w3.org/
TR/cors/
• SNIA TLS Specification for Storage Systems. 20 November 2014. http://www.snia.org/tls/
• DMTF DSP0270 Redfish Host Interface Specification, http://www.dmtf.org/sites/default/files/
standards/documents/DSP0270_1.0.pdf
3. Terms and definitions
In this document, some terms have a specific meaning beyond the normal English meaning. Those terms
are defined in this clause.
The terms "shall" ("required"), "shall not", "should" ("recommended"), "should not" ("not recommended"),
"may", "need not" ("not required"), "can" and "cannot" in this document are to be interpreted as described
in ISO/IEC Directives, Part 2, Annex H. The terms in parenthesis are alternatives for the preceding term,
for use in exceptional cases when the preceding term cannot be used for linguistic reasons. Note that
ISO/IEC Directives, Part 2, Annex H specifies additional alternatives. Occurrences of such additional
alternatives shall be interpreted in their normal English meaning.
The terms "clause", "subclause", "paragraph", and "annex" in this document are to be interpreted as
described in ISO/IEC Directives, Part 2, Clause 5.
Version 1.2.0 Published 9
2 © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
The terms "normative" and "informative" in this document are to be interpreted as described in ISO/IEC
Directives, Part 2, Clause 3. In this document, clauses, subclauses, or annexes labeled "(informative)" do
not contain normative content. Notes and examples are always informative elements.
The following additional terms are used in this document.
Term Definition
An embedded device or service, typically an independent microprocessor or
Baseboard
System-on-Chip with associated firmware, within a Computer System used to
Management
perform systems monitoring and management-related tasks, which are commonly
Controller
performed out-of-band.
Collection See Resource Collection.
CRUD Basic intrinsic operations used by any interface: Create, Read, Update and Delete.
Event A record that corresponds to an individual alert.
Managed In the context of this specification, a managed system is a system that provides
System information or status, or is controllable, via a Redfish-defined interface.
Member A Member is a single resource instance contained in a Resource Collection
A complete request or response, formatted in HTTP/HTTPS. The protocol, based
Message on REST, is a request/response protocol where every Request should result in a
Response.
The HTTP request methods that map generic CRUD operations. These are POST,
Operation
GET, PUT/PATCH, HEAD and DELETE.
OData The Open Data Protocol, as defined in OData-Protocol.
The name for a resource that provides information about the Service Root. The
OData
Service Document provides a standard format for enumerating the resources
Service
exposed by the service that enables generic hypermedia-driven OData clients to
Document
navigate to the resources of the Redfish Service.
The name for the functionality that receives alerts from a Redfish Service. This
Redfish Alert
functionality is typically software running on a remote system that is separate from
Receiver
the managed system.
Redfish Name for the functionality that communicates with a Redfish Service and accesses
Client one or more resources or functions of the Service.
Redfish The set of protocols that are used to discover, connect to, and inter-communicate
Protocol with a Redfish Service.
10 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved 3

DSP0266 Redfish Scalable Platforms Management API Specification
Term Definition
The Schema definitions for Redfish resources. It is defined according to OData
Redfish
Schema representation that can be directly translated to a JSON Schema
Schema
representation.
Also referred to as the "Service". The set of functionality that implements the
Redfish
protocols, resources, and functions that deliver the interface defined by this
Service
specification and its associated behaviors for one or more managed systems.
Redfish Also referred to as "Service Entry Point". The interface through which a particular
Service instance of a Redfish Service is accessed. A Redfish Service may have more than
Entry Point one Service Entry Point.
A message from a Client to a Server. It consists of a request line (which includes
Request
the Operation), request headers, an empty line and an optional message body.
A Resource is addressable by a URI and is able to receive and process messages.
Resource A Resource can be either an individual entity, or a Collection that acts as a
container for several other entities.
A Resource Collection is a Resource that acts as a container of other Resources.
The Members of a Resource Collection usually have similar characteristics. The
Resource
container processes messages sent to the container. The Members of the
Collection
container process messages sent only to that Member without affecting other
Members of the container.
A Resource Tree is a tree structure of JSON encoded resources accessible via a
well-known starting URI. A client may discover the resources available on a
Resource Redfish Service by following the resource links from the base of the tree.
Tree NOTE for Redfish client implementation: Although the resources are a tree, the
references between resources may result in graph instead of a tree. Clients
traversing the resource tree must contain logic to avoid infinite loops.
A message from a Server to a Client in response to a request message. It consists
Response
of a status line, response headers, an empty line and an optional message body.
The term Service Root is used to refer to a particular resource that is directly
accessed via the service entry point. This resource serves as the starting point for
Service Root
locating and accessing the other resources and associated metadata that together
make up an instance of a Redfish Service.
Subscription The act of registering a destination for the reception of events.
Version 1.2.0 Published 11
4 © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
4. Symbols and abbreviated terms
The following additional abbreviations are used in this document.
Term Definition
BMC Baseboard Management Controller
CRUD Create, Replace, Update and Delete
CSRF Cross-Site Request Forgery
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol over TLS
IP Internet Protocol
IPMI Intelligent Platform Management Interface
JSON JavaScript Object Notation
KVM-IP Keyboard, Video, Mouse redirection over IP
NIC Network Interface Card
PCI Peripheral Component Interconnect
PCIe PCI Express
TCP Transmission Control Protocol
XSS Cross-Site Scripting
5. Overview
The Redfish Scalable Platforms Management API ("Redfish") is a management standard using a data
model representation inside of a hypermedia RESTful interface. Because it is based on REST, Redfish is
easier to use and implement than many other solutions. Since it is model oriented, it is capable of
expressing the relationships between components in modern systems as well as the semantics of the
services and components within them. It is also easily extensible. By using a hypermedia approach to
REST, Redfish can express a large variety of systems from multiple vendors. By requiring JSON
representation, a wide variety of resources can be created in a denormalized fashion not only to improve
scalability, but the payload can be easily interpreted by most programming environments as well as being
relatively intuitive for a human examining the data. The model is exposed in terms of an interoperable
12 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved 5

DSP0266 Redfish Scalable Platforms Management API Specification
Redfish Schema, expressed in an OData Schema representation with translations to a JSON Schema
representation, with the payload of the messages being expressed in a JSON following OData JSON
conventions. The ability to externally host the Redfish Schema definition of the resources in a machine-
readable format allows the meta data to be associated with the data without encumbering Redfish
Services with the meta data, thus enabling more advanced client scenarios as found in many data center
and cloud environments.
5.1. Scope
The scope of this specification is to define the protocols, data model, and behaviors, as well as other
architectural components needed for an inter-operable, cross-vendor, remote and out-of-band capable
interface that meets the expectations of Cloud and Web-based IT professionals for scalable platform
management. While large scale systems are the primary focus, the specifications are also capable of
being used for more traditional system platform management implementations.
The specifications define elements that are mandatory for all Redfish implementations as well as optional
elements that can be chosen by system vendor or manufacturer. The specifications also define points at
which OEM (system vendor) -specific extensions can be provided by a given implementation.
The specifications set normative requirements for Redfish Services and associated materials, such as
Redfish Schema files. In general, the specifications do not set requirements for Redfish clients, but will
indicate what a Redfish client should do in order to access and utilize a Redfish Service successfully and
effectively.
The specifications do not set requirements that particular hardware or firmware must be used to
implement the Redfish interfaces and functions.
5.2. Goals
There are many objectives and goals of Redfish as an architecture, as a data representation, and of the
definition of the protocols that are used to access and interact with a Redfish Service. Redfish seeks to
provide specifications that meet the following goals:
• Scalable – To support stand-alone machines to racks of equipment found in cloud service
environments.
• Flexible – To support a wide variety of systems found in service today.
• Extensible – To support new and vendor-specific capabilities cleanly within the framework of the
data model.
• Backward Compatible - To enable new capabilities to be added while preserving investments in
earlier versions of the specifications.
• Interoperable – To provide a useful, required baseline that ensures common level of functionality
and implementation consistency across multiple vendors.
• System-Focused – To efficiently support the most commonly required platform hardware
Version 1.2.0 Published 13
6 © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
management capabilities that are used in scalable environments, while also being capable of
managing current server environments.
• Standards based – To leverage protocols and standards that are widely accepted and used in
environments today - in particular, programming environments that are being widely adopted for
developing web-based clients today.
• Simple – To be directly usable by software developers without requiring highly specialized
programming skills or systems knowledge.
• Lightweight – To reduce the complexity and cost of implementing and validating Redfish
Services on managed systems.
5.3. Design tenets
The following design tenets and technologies are used to help deliver the previously stated goals and
characteristics:
• Provide a RESTful interface using a JSON payload and an Entity Data Model
• Separate protocol from data model, allowing them to be revised independently
• Specify versioning rules for protocols and schema
• Leverage strength of internet protocol standards where it meets architectural requirements, such
as JSON, HTTP, OData, and the RFCs referenced by this document.
• Focus on out-of-band access -- implementable on existing BMC and firmware products
• Organize the schema to present value-add features alongside standardized items
• Make data definitions as obvious in context as possible
• Maintain implementation flexibility. Do not tie the interface to any particular underlying
implementation architecture. "Standardize the interface, not the implementation."
• Focus on most widely used 'common denominator' capabilities. Avoid adding complexity to
address functions that are only valued by a small percentage of users.
• Avoid placing complexity on the management controller to support operations that can be better
done at the client.
5.4. Limitations
Redfish does not guarantee that client software will never need to be updated. Examples that may require
updates include accommodation of new types of systems or their components, data model updates, and
so on. System optimization for an application will always require architectural oversight. However, Redfish
does attempt to minimize instances of forced upgrades to clients using Schemas, strict versioning and
forward compatibility rules and through separation of the protocols from the data model.
Inter-operable does not mean identical. A Redfish client may need to adapt to the optional elements that
are provided by different vendors. Implementation and configurations of a particular product from a given
vendor can also vary.
For example, Redfish does not enable a client to read a Resource Tree and write it to another Redfish
14 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved 7

DSP0266 Redfish Scalable Platforms Management API Specification
Service. This is not possible as it is a hypermedia API. Only the root object has a well known URI. The
resource topology reflects the topology of the system and devices it represents. Consequently, different
server or device types will result in differently shaped resource trees, potentially even for identical
systems from the same manufacturer.
Additionally, not all Redfish resources are simple read/write resources. Implementations may follow other
interaction patterns discussed later. As an example, user credentials or certificates cannot simply be read
from one service and transplanted to another. Another example is the use of Setting Data instead of
writing to the same resource that was read from.
Lastly, the value of links between resources and other elements can vary across implementations. Clients
should not assume that links can be reused across different instantiations of a Redfish Service.
5.5. Additional design background and rationale
5.5.1. REST-based
This document defines a RESTful interface. Many service applications are exposed as RESTful
interfaces.
There are several reasons to define a RESTful interface:
• It enables a lightweight implementation, where economy is a necessity (smaller data transmitted
than SOAP, fewer layers to the protocol than WS-Man).
• It is a prevalent access method in the industry.
• It is easy to learn and easy to document.
• There are a number of toolkits & development environments that can be used for REST.
• It supports data model semantics and maps easily to the common CRUD operations.
• It fits with our design principle of simplicity.
• It is equally applicable to software application space as it is for embedded environments thus
enabling convergence and sharing of code of components within the management ecosystem.
• It is schema agnostic so adapts well to any modeling language.
• By using it, Redfish can leverage existing security & discovery mechanisms in the industry.
5.5.2. Follow OData conventions
With the popularity of RESTful APIs, there are nearly as many RESTful interfaces as there are
applications. While following REST patterns helps promote good practices, due to design differences
between the many RESTful APIs there is no interoperability between them.
OData defines a set of common RESTful conventions and markup which, if adopted, provides for
interoperability between APIs.
Adopting OData conventions for describing Redfish Schema, URL conventions, and naming and structure
Version 1.2.0 Published 15
8 © ISO/IEC 2018 – All rights reserved

Redfish Scalable Platforms Management API Specification DSP0266
of common properties in a JSON payload, not only encapsulate best practices for RESTful APIs but
further enables Redfish Services to be consumed by a growing ecosystem of generic client libraries,
applications, and tools.
5.5.3. Model-oriented
The Redfish model is built for managing systems. All resources are defined in OData Schema
representation and translated to JSON Schema representation. OData is an industry standard that
encapsulates best practices for RESTful services and provides interoperability across services of different
types. JSON is being widely adopted in multiple disciplines and has a large number of tools and
programming languages that accelerate development when adopting these approaches.
5.5.4. Separation of protocol from data model
The protocol operations are specified independently of the data model. The protocols are also versioned
independently of the data model. The expectation is that the protocol version changes extremely
infrequently, while the data model version is allowed to change as needed. This implies that innovation
should happen primarily in the data model, not the protocols. It allows the data model to be extended and
changed as needed without requiring the protocols or API version to change. Conversely, separating the
protocols from the data model allows for changes to occur in the protocols without causing significant
changes to the data model.
5.5.5. Hypermedia API service endpoint
Like other hypermedia APIs, Redfish has a single service endpoint URI and all other resources are
accessible via opaque URIs referenced from the root. Any resource discovered through links found by
accessing the root service or any service or resource referenced using references from the root service
will conform to the same versions of the protocols supported by the root service.
5.6. Service elements
5.6.1. Synchronous and asynchronous operation support
While the majority of operations in this architecture are synchronous in nature, some operations can take
a long time to execute, more time than a client typically wants to wait. For this reason, some operations
can be asynchronous at the discretion of the service. The request portion of an asynchronous operation is
no different from the request portion of a synchronous operation.
The use of HTTP Response codes enable a client to determine if the operation was completed
synchronously or asynchronously. For more information, see the clause on Tasks.
16 Published Version 1.2.0
© ISO/IEC 2018 – All rights reserved 9

DSP0266 Redfish Scalable Platforms Management API Specification
5.6.2. Eventing mechanism
In some situations it is useful for a service to provide messages to clients th
...