7.数据模型与格式

Redfish接口的一个关键职责就是分离协议与数据模型。本章节将描述通用数据模型，资源和Redfish格式的需求。

  • 每一个资源都应该是符合资源类型定义的强类型对象。类型应该被定义在一个格式文档中，并通过唯一的类型标识符来确定。

7.1 类型标识符

类型是通过一个类型的URI来标识的。类型URI的全称格式如下： *#名称空间.类型名* 这里的：

  • 名称空间 = 被定义类型名称空间的全名或别名
  • 类型名 = 类型名称

本规范中的定义类型全名称格式如下： 资源类型名.主版本号.次版本号.修订版本号 这里：

  • 资源类型名 = 资源类型的名称。对于结构体，枚举和动作来说，它一般是指容器资源的名称
  • 主版本号 = 整数值：主要是用于标识哪些向后不兼容的类内部修改
  • 次版本号 = 整数值：用于比较小的调整。新的属性被添加但是没有东西被移除。保持与上一次版本的兼容性。
  • 修订版本号 = 整数值：之前的版本有损坏并且需要修复

一个有效的类型名称空间例子是这样的“System.0.96.0”

7.1.1 JSON中的类型标识符

在有效JSON数据里中使用的类型应该通过服务元数据来定义和引用。 当本规范中已定义的资源类型在JSON文档中引用时，应该使用全名称空间的名字。 当非资源类型在JSON文档中引用时，需要使用服务元数据定义中的版本无关的名称空间别名。 注意：关于数据模型与格式的安全影响会在安全章节进行描述。

7.2 通用命名规则

Redfish意图提供更加直观并且易于理解的接口。对于不熟悉这种新型发现属性的用户来说，一致性有助于他们来理解它的用法。尽管命名规则不能替代规范与格式中的标准信息，但是遵从这些规则有助于可读性以及客户端的使用。 资源名，属性名，和常量如枚举类型应该使用Pascal命名规则：

  • 每个单词的首字母应该大写，单词间不允许有空格（如PowerState, SerialNumber)
  • 不使用下划线
  • 如果是两个字母的缩写词必须是大写（如IPAddress, RemoteIP)
  • 只有缩写词具有三个或更多字符时，第一个字符应该被大写，除非它是一个 Pascal格式标识符的第一个单词（如Wwn, VirtualWwn)

但有些情况需要例外处理：

  • 众所周知的技术名称，如“iSCSI”
  • 产品名称，如“iLO”
  • 众所周知的缩写或是首字母缩写词

对于那些属性中带有单位的，或是有特殊意义的，单位标识应该放到名称的尾部，如：

  • 带宽（Mbps),(如 PostSpeedMbps)
  • CPU速度（Mhz），（如 ProcessorSpeedMhz）
  • 内存容量（MegaBytes，MB），（如 MemoryMB）
  • 元素个数（Count），（如 ProcessorCount， FanCount）
  • 资源的状态（State），（如 PowerState）
  • 状态值，如果正在被处理的工作，在单词结尾需要使用（ing），（如Applying, Clearing)

7.3 本地化考量

Redfish架构支持本地化字符串，但是并不在本地化服务上做任何强制性的要求。就目前的市场而言，本地化是一个必选项（如Schemas）。Schema-supplied显示的字符串可能是必须本地化，但是一个Schema文件只会包含一种语言。可选语言的schema可能会被发布并在Redfish的客户端上可用，但是可能不需要通过Redfish的schema存储来提供。 Redfish schema里面属性名定义是不需要本地化的。用户提供的字符串属性值如资产标签是可能需要本地化的。可本地化的字符串属性值应该以IsLanguageDependent术语来标注.

7.4 Schema定义

独立的资源和它们依赖的类型与动作被定义在了一个单独的Schema文档中。

7.4.1 通用注解

所有的Redfish类型和属性应该包含描述和长描述注解。

7.4.1.1 描述

描述注解可以应用到任何类型，属性，动作或者参数上，主要目的是为了Schema元素提供可读的说明。 描述注解的定义可以访问这个链接

7.4.1.2 长描述

长描述注解术语可以应用到任何类型，属性，动作或者参数上，主要是为Schema 元素提供一份正式的，规范的指南。 长描述注解定义可以访问这个链接

7.4.2 模式文档

独立资源被定义成实体类型，该类型附带一个根据OData-Schema规范生成的OData模式展现。 展现形式可能包括注解，以便验证自动生成的JSON的有效负载。 OData模式展现文档的外围元素是Edmx元素，必须是一个“版本”的属性并且值为“4.0”

<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
<!-- edmx:Reference and edmx:DataService elements go here --> 
</edmx:Edmx>
7.4.2.1 其他模式的参照

Redfish模式中可能会引用其他模式文档中的类型定义。OData模式展现就是通过包含一个引用元素来完成的。而JSON模式展现是通过$ref属性来实现的。 该参考元素指定了OData模式展现文档的URI。该URI描述被引用的类型并拥有一个或更多的子元素。这些子元素指定了被引用类型的名称空间属性，以及该名称空间的可选别名属性。 类型定义通常引用OData和Redfish名称空间来作为普通型注解术语，并且资源类型定义引用Redfish资源1.0.0的名称空间用于基本类型。Redfish的OData模式展现通常包括OData的度量名称空间，它包含诸如温度，速度或者尺寸等指标。

<edmx:Reference Uri="http://docs.oasis-open.org/odata/odata/v4.0/cs01/vocabularies /Org.OData.Core.V1.xml">
    <edmx:Include Namespace="Org.OData.Core.V1" Alias="OData"/> 
</edmx:Reference> 
<edmx:Reference Uri="http://docs.oasis-open.org/odata/odata/v4.0/os/vocabularies/Org.OData.Measures.V1.xml">
    <edmx:Include Namespace="Org.OData.Measures.V1" Alias="OData.Measures"/>
</edmx:Reference> 
<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/RedfishExtensions.xml">
    <edmx:Include Namespace="RedfishExtensions.1.0.0" Alias="Redfish"/> 
</edmx:Reference> 
<edmx:Reference Uri="http://redfish.dmtf.org/schemas/v1/Resource.xml"> 
    <edmx:Include Namespace="Resource"/>
    <edmx:Include Namespace="Resource.1.0.0"/> 
</edmx:Reference>
7.4.2.2 名称空间定义

资源类型通过名称空间来定义。名称空间通过一个Schema元素来定义，该元素包含Namespace和Alias两个属性。Schema元素是DataSevices的子元素，而DataServices元素是Edmx的子元素。

<edmx:DataServices>
    <Schema xmlns="http://docs.oasis-open.org/odata/ns/edm" Namespace="MyTypes.0.96.0" Alias="MyTypes">
    <!-- Type definitions go here -->
    </Schema>
</edmx:DataServices>

7.4.3 资源类型定义

资源类型被定义为带有名称空间的实体类型元素。Name属性指明资源的名称，BaseType指明是基本类型。 Redfish资源起源于一个通用资源基本类型，在资源名称空间0.96.0里称之为“Resource”。 实体类型包含属性和导航属性元素用于定义资源，同时注解元素用于描述资源。

<EntityType Name="TypeA" BaseType="Resource.Resource">
    <Annotation Term="Core.Description" String="This is the description of TypeA."/>
    <Annotation Term="Core.LongDescription" String="This is the specification of TypeA."/>
    <!-- Property and Navigation Property definitions go here -->
</EntityType>

所有的资源都应包含Description和LongDescription注解。

7.4.4 资源属性

资源的属性结构通过“Property”元素来定义。Name标志指示属性的名称，Type元素表示类型。非空值的属性必须将nullable标志设置为“false”

<Property Name="Property1" Type="Edm.String" Nullable="false">
    <Annotation Term="Core.Description" String="This is a property of TypeA."/>
    <Annotation Term="Core.LongDescription" String="This is the specification of Property1."/>
    <Annotation Term="OData.Permissions" EnumMember="OData.Permissions/Read"/>
    <Annotation Term="DMTF.Required"/>
    <Annotation Term="OData.Measures.Unit" String="Watts"/>
</Property>

所有的属性应包含Description和LongDescription注解。 只读属性必须将Permission标志的值设置为“ODataPermissions/Read”。 要求被所有服务实现的属性需要标注成required annotation。 带有单位的属性可以被标注成units annotation。

7.4.4.1 属性类型

属性的类型通过Type标志来指明。它的值可能是原子类型，结构体类型，枚举类型或者这些类型的集合。

7.4.4.1.1 原子类型

前缀带有Edm名称空间的类型为原子类型。 Redfish服务支持的原子类型有：

类型 含义
Edm.Boolean True 或者 False
Edm.DateTimeOffset 带时区的日期和时间
Edm.Decimal 带有固定精度并可扩展的数值类型
Edm.Double IEEE 754 标准中的64位浮点数 (15-17小数点)
Edm.Duration 以日，时，分和秒组成的有符号持续时间
Edm.Int64 有符号64位整数
Edm.String 以UTF-8编码的字符序列
7.4.4.1.2 结构体类型

结构体类型被定义为带有名称空间的ComplexType元素。它的Name属性指示了结构体类型的名字。复合类型可以通过BaseType标志来指明包含一个基本类型，如果有的话。 结构体类型可以跨不同资源类型的不同属性来重用。

<ComplexType Name="PropertyTypeA"> 
    <Annotation Term="Core.Description" String="This is type used to describe a structured property."/> 
    <Annotation Term="Core.LongDescription" String="This is the specification of the type."/>
    <!-- Property and Reference Property definitions go here -->
</ComplexType>

结构体类型可以包含属性，引用属性和注解。 结构体类型也应该包含Description和LongDescription注解。

7.4.4.1.3 枚举

枚举类型被定义为带有名称空间的EnumType元素。它的Name属性指示了枚举类型的名字。 枚举类型可以跨不同资源类型的不同属性来重用。 枚举类型包含Member元素，它定义了枚举的成员。Member元素含有一个Name标记用于指示成员名称字串。

<EnumType Name="EnumTypeA"> 
    <Annotation Term="Core.Description" String="This is the EnumTypeA enumeration."/> 
    <Annotation Term="Core.LongDescription" String="This is used to describe the EnumTypeA enumeration."/> 
    <Member Name="MemberA"> 
        <Annotation Term="Core.Description" String="Description of MemberA"/> 
    </Member> 
    <Member Name="MemberB"> 
        <Annotation Term="Core.Description" String="Description of MemberB"/> 
    </Member> 
</EnumType>

枚举类型应该包含Description和LongDescription注解。 枚举成员应该包含Description注解。

7.4.4.1.4 集合

该类型属性可能指示一个原子类型，结构体或枚举类型的集合。 这个类型的值用于一个值化集合属性的格式如下： Collection(NamespaceQualifiedTypeName) NamespaceQualifiedTypeName指的是原子类型，结构体或枚举类型的名称空间全限定名。

7.4.4.2 附加属性

AdditionalProperties注解被用于指示一个类型是否可以包含哪些既定类型之外的附加属性。如果一个类型的AdditionalProperties注解值为“False”，那么就一定不能包含附加属性。

<Annotation Term="OData.AdditionalProperties"/>

AdditionalProperties注解的相关定义在这里

7.4.4.3 非空属性

非空属性元素可能包含一个值为“False”的Nullable属性用于指示该元素不能包含空值。一个属性元素如果是带有Nullable属性值为“True”或者没有Nullable属性的情况下，可以接受空值。

 <Property Name="Property1" Type="Edm.String" Nullable="false">
7.4.4.4 只读属性

许可注解条款可以被应用到属性上，通过设置“ OData.Permissions/Read ”值来指示该属性为只读。

 <Annotation Term="OData.Permissions" EnumMember="OData.Permissions/Read"/>

许可注解条款的定义在这里

7.4.4.5 必需属性

必需注解条款被用于指明一个属性必需被某个服务支持。属性如果没有被标注为必需的，或者标注的属性值为“False”，那么该属性就是可选的。 如果具体实现支持了该属性，那么它应该总是为这个属性提供一个值。如果该值是未知的，那么空值在大多数情况下是可接受的。属性不会从GET操作返回，GET操作应该指示这个属性不被当前服务所支持。

 <Annotation Term="Redfish.Required"/>
7.4.4.6 必需属性的创建

RequiredOnCreate的注解条款被用于指示在一个资源被创建时该属性必需指定。属性如果不带有RequiredOnCreate标记，或者该标记的属性值为“False”,那么创建时该属性就不是必需的。

 <Annotation Term="Redfish.RequiredOnCreate"/>

RequiredOnCreate注解的定义在这里

7.4.4.7 度量单位

另外遵从命名规范，属性表达的度量单位应该带有Unit注解条款，目的是指示用于属性的度量单位。

 <Annotation Term="OData.Measures.Unit" String="Watts"/>

Unit注解条款定义在这里

7.4.5 引用属性

引用其他资源的属性被表达成引用属性，使用的是NavigationProperty元素。NavigationProperty元素指示Name和相关资源的名称空间全限定类型。如果属性引用的是一个单独类型，那么该类型属性的值就是相关资源类型的名称空间全限定名。

<NavigationProperty Name="RelatedType" Type="MyTypes.TypeB"> 
    <Annotation Term="Core.Description" String="This property references a related resource."/> 
    <Annotation Term="Core.LongDescription" String="This is the specification of the related property."/> 
    <Annotation Term="OData.AutoExpandReferences"/> </NavigationProperty>

如果属性引用的是一个资源集合，那么类型属性值如下：

Collection(NamespaceQualifiedTypeName)

这里的 NamespaceQualifiedTypeName 就是相关资源类型的名称空间全限定名。

<NavigationProperty Name="RelatedTypes" Type="Collection(MyTypes.TypeB)"> 
    <Annotation Term="Core.Description" String="This property represents a collection of related resources."/> 
    <Annotation Term="Core.LongDescription" String="This is the specification of the related property."/> 
    <Annotation Term="OData.AutoExpandReferences"/> 
</NavigationProperty>

所有的引用类型都应该包含Description和LongDescription注解。

7.4.5.1 包容资源

引用属性的成员被引用资源包含，通过ContainsTarget属性值为True来指示该属性。 例如，为了表明机箱资源上具有一个电源资源，你要将ContainsTarget=True放到具有机箱类型定义的电源资源上。

<NavigationProperty Name="Power" Type="Power.Power" ContainsTarget="true"> 
    <Annotation Term="OData.Description" String="A reference to the power properties (power supplies, power policies, sensors) for this chassis."/> 
    <Annotation Term="OData.LongDescription" String="The value of this property shall be a reference to the resource that represents the power characteristics of this chassis and shall be of type Power."/> 
    <Annotation Term="OData.AutoExpandReferences"/> 
</NavigationProperty>
7.4.5.2 扩展引用

在Redfish的JSON有效负载里的引用属性被扩展为包含相关资源id和相关资源id的集合。这个行为通过AutoExpandReferences注解来表达。

<Annotation Term="OData.AutoExpandReferences"/>

AutoExpandReferences注解的定义在这里

7.4.5.3 扩展资源

该条款可以被应用到引用属性上，用于指示该服务的默认行为是在响应中扩展相关资源或资源集合。

<Annotation Term="OData.AutoExpand"/>

AutoExpand注解的定义在这里

7.4.6 资源操作

操作可以通过名为“Actions”的属性来分组。

 <Property Name="Actions" Type="MyType.Actions">

Actions属性是一个带有单独OEM属性的结构体类型。OEM属性的类型是一个未定义的结构体类型。

 <ComplexType Name="Actions"> 
     <Property Name="OEM" Type="MyType.OEMActions"/> 
</ComplexType>

<ComplexType Name="OEMActions"/>

独立的操作被定义为带有名称空间的Action元素。操作的Name属性指示操作名称。IsBound属性指示这个操作被绑定到了（被作为成员）一个资源或结构体上。 Action元素包含一个或多个Parameter元素，每个Parameter元素上都有Name和Type属性。 第一个参数叫做“绑定参数”并且指示该操作是某个资源或结构类型上的成员（资源上的Actions属性的类型）。余下的Parameter元素是描述传递给操作的额外的参数信息。

 <Action Name="MyAction" IsBound="true"> 
     <Parameter Name="Thing" Type="MyType.Actions"/> 
    <Parameter Name="Parameter1" Type="Edm.Boolean"/> 
</Action>

7.4.7 资源扩展性

商业公司，OEM和其他组织可以为一般的Redfish资源定义额外的属性，链接和动作，使用OEM属性上的资源，连接和动作来完成。 尽管这些扩展的信息和语义超出了本标准范围，但是展现数据的模式，资源本身以及协议周围的语义也应该符合本规范的要求。

7.4.7.1 Oem属性

在本节的上下文中，“OEM”的术语是指代任何公司，厂商或者组织，那些机构正在对已发布的DMTF模式与功能提供或定义扩展用于Redfish。用于指定的Redfish资源的基本模式包含一个空的复合类型，称之为“Oem”它的值可以用于封装一个或多个指定的OEM复合属性。在标准Redfish模式中的Oem属性是一个预定义的占位符，它主要是为了可用于指定的OEM属性定义。 Oem属性的正确用法要求为指定的OEM复合类型定义元数据，那样才可能被Oem属性所引用。以下的片段是一个XML模式的例子，它演示了在复合类型“AnvilType1”下定义一对指定的OEM属性（其他模式元素通常会表示成，如XML和OData之类的模式描述标识，这些并没有在这个简单里例子中展示出来）。

 <Schema Name="Contoso.v.v.v">  
     ... 
    <ComplexType Name="AnvilType1"> 
        <Property Name="slogan" Type="Edm.String"/> 
        <Property Name="disclaimer" Type="Edm.String"/> 
    </ComplexType>  
    ... 
</Schema>

下一个片段展示了一个例子关于以前的模式与“AnvilType1”属性类型可能会出现在实例化的Oem属性中，作为在资源上进行一次GET的结果。该例子演示了在Oem属性的使用中两个必要的元素：用于对象的名字和用于对象的类型属性。用于这些元素的详细需求如下：

...
      "Oem": {    
         "Contoso": {      
            "@odata.type": "http://Contoso.com/schemas/extensions.v.v.v#contoso.AnvilType1",      
            "slogan": "Contoso anvils never fail",      
            "disclaimer": "* Most of the time" 
          } 
       } 
...
7.4.7.2 Oem属性格式与内容

包含具有Oem属性的Oem-Specificed对象在内必须是一个有效的JSON对象，它要符合Redfish复合类型的格式。对象（属性）的名称必须是能唯一标识OEM或者机构。下面的章节将表述更多细节。Oem-Specific属性也应该包含一个具体的类型属性用于提供模式的位置和带有该模式的属性的类型定义。Oem属性可能持有多个指定的Oem对象，包括并不仅限于一个公司或组织。 包含任何其他带有Oem-Specific复合类型的属性定义在内，单独具有功能规范，验证，或者其他需求用于这些内容的就是Oem-Specific，并且在本规范范围之外。当然这里没有任何的Oem-Specific在对具有一个Oem-Specificed JSON对象的Oem-Specificed元素的大小和复杂度进行限制，它的意图是OEM属性将通常只被用于少量的简单属性，目的是参数化Redfish资源。如果有大量的对象或者大量的数据要被支持，那么OEM需要考虑用Oem-Specificed对象指向一个独立资源用于他们的扩展。

7.4.7.3 Oem属性命名

具有Oem属性的Oem-Specificed对象使用一个唯一的OEM标识符来命名，它用于被定义属性的名称空间的顶部。这里有两个指定的格式用于标识符。标识符应该即是一个ICANN-recognized域名（包括顶层域后缀），或一个IANA-assigned的企业号码，前缀是“EID:”。 使用“.com”为域名的组织可能会遗漏掉“.com”后缀（如，Contoso.com可能被写成"Contoso"，但是Contoso.org必须使用“Contoso.org”作为OEM属性名）。OEM标识符的域名部分应该是大小写无关的。如，文本"Contoso.biz"，"contoso.BIZ"，“conTOso.biZ”等等，所有这些都指向相同的OEM并且是顶层的名称空间。

属性名的标识符部分可能跟随着一个冒号和其他附加字符串，来允许按照OEM厂商的期望对OEM-specified对象进行进一步的名称空间分隔，例如“Contoso.com:xxxx"或"EID:412:xxxx”。跟在冒号后面的文本就是完整的OEM-specific。OEM-specificed扩展后缀可能是大小写敏感的，这取决于OEM。一般的客户端软件应该处理这些扩展，如出现的话, 作为不透明处理，不用尝试去分析和解释这些内容。

这样的后缀可以通过很多种方式来使用，这取决于OEM的需求。例如，Consoto公司可能有一个作“研究”的子机构，在这种情况下OEM-specified属性名可能被扩展成“Contoso:Research”。另外，它可以标示一个名称空间用于功能区，地理，子公司等。

名称的OEM标识符部分通常用于标识公司或组织，它创建并维护该属性的模式。但是这并不是一个要求。该标识符只要求唯一标识名称空间的顶层管理器，目的是防止不同供应商与组织之间的OEM属性定义的冲突。所以，处于名称空间顶部的组织可能不同于提供OEM-specified属性定义的组织。例如，Contoso可能允许他们的一个客户，如“CustomerA”，去扩展Contoso的产品，在带有确切的CustomerA专有属性情况下。在这种情况下，尽管Contoso分配了名称“contosos:customers.CustomerA”,但它可能指的是在该名称空间下定义了内容和功能的CustomerA。在任何时候，OEM标识符只能用在带有许可或被识别了的公司和组织上。

7.4.8 Oem属性示例

下面的片段展现的是一些命名的例子和Oem属性的用法，它可能出现在访问一个资源的时候。例子显示了OEM标识符可以有不同的格式，这样OEM-specified内容可以是简单的或复杂的，并且OEM标识符的扩展的用法和格式实际上就是OEM-specific。

 ...

"Oem": {
        "Contoso": {
            "@odata.type": "http://contoso.com/schemas/extensions.v.v.v#contoso.AnvilTypes1", 
            "slogan": "Contoso anvils never fail",
            "disclaimer": "* Most of the time"
        },
        "Contoso.biz": {
            "@odata.type": "http://contoso.biz/schemas/extension1.1#RelatedSpeed",
            "speed" : "ludicrous"
        },
        "EID:412:ASB_123": {
            "@odata.type": "http://AnotherStandardsBody/schemas.1.0.1#powerInfoExt", 
            "readingInfo": {
                "readingAccuracy": "5",
                "readingInterval": "20"
              }
        },
        "Contoso:customers.customerA": {
            "@odata.type" : "http://slingShots.customerA.com/catExt.2015#slingPower", 
            "AvailableTargets" : [ "rabbit", "duck", "runner" ], 
            "launchPowerOptions" : [ "low", "medium", "eliminate" ],
            "powerSetting" : "eliminate",
            "targetSetting" : "rabbit"
        }
} 
...

7.4.8.1 定制的行为

OEM-specific操作可以通过定义操作绑定到资源的行为属性类型上的OEM类型。

 <Schema>
     <Action Name="Ping" IsBound="true">
        <Parameter Name="ContosoType" Type="MyType.OEMActions"/>
      </Action>
</Schema>

诸如出现在有效JSON负载中的绑定行为可以作为Oem类型的属性，内嵌在Actions属性里面。

 "Actions": {
    "OEM": {
        "Contoso.v.v.v#Contoso.Ping": {
                "target":"/redfish/v1/Systems/1/Actions/OEM/Contoso.Ping"
        } 
    }
}

7.4.8.2 定制的惯例

本规范定义了一个通用注解集用于扩展Redfish的资源类型定义。另外，服务也可能定义定制的注解。 服务可能应用注解到资源上，目的是去提供类型的service-specific信息，诸如服务是否支持部分属性的修改。 在这些资源还没有定义任何值用于注解，服务可以应用注解到已存在的资源上。服务不能改变一个注解的值，如果这个注解已作为资源定义的一部分。 由于服务注解可能被应用到已存在的资源定义上，它们通常在被服务元素引用的service-secific元数据文档中进行详细说明。

7.5 通用的Redfish资源属性

本节包含一个跨所有Redfish资源的通用属性集。本节中的属性名称不应被用于任何其他目的，即便它们没有被特定的资源所实现。 通用属性被定义在基础资源Redfish模式（base Resource Redfish Schema）中。定义在Resource.xml中的部分用于OData模式展现，定义在Resource.1.0.0.json中的部分则用于JSON模式展现。

7.5.1 Id

资源的Id属性用于标识集合中的一个资源。

7.5.2 名称

名称属性被用于表达一个人类可读的别名。名称属性的类型应该是字符串类型。

7.5.3 描述

描述属性被用于表达一个人类可读的说明。描述属性的类型也应该是字符串类型。

7.5.4 状态

状态属性表达资源的状态。 状态属性的值是一个规范定义了的通用状态对象类型。通过拥有一个状态的通用展现，客户端可以依赖在一致语义上。状态对象可以表面当前预期的状态，资源已经请求改变的状态，当前真实的状态以及任何影响资源的当前状态问题。

7.5.5 链接

链接属性表达链接关联的资源，如资源模式定义中定义的。所有被关联的引用属性应该嵌入到链接属性之下。所有直接的（附属的）被引用属性应该位于资源的根当中。

7.5.6 RelatedItem

RelatedItem属性表达连接到资源（或部分资源）如在资源模式定义中定义的。它并不意图像其他引用那样去作为一个强连接方法。相反的它被用于表达元素与子元素间的关系在服务的不同部分间。例如，风扇可能位于实现的某个地方而处理器在另外一个地方，RelatedItem可以被用于告知客户端有一个元素关联到了另一个元素（如，风扇正在给处理器降温）。

7.5.7 动作

动作属性包含资源所支持的相关动作。

7.5.8 OEM

OEM属性被用于OEM扩展如模式扩展性里定义的。

7.6 Redfish资源

Redfish架构总体而言是一个资源描述集合包含本规范已确定的实现层面的标准化需求。 Redfish资源有几个根本成分：

  • 根服务资源
    • 包含部分服务实例的映射到可采用的subtending资源 *包含服务实例的UUID。这个UUID与SSDP发现返回的UUID一致。
  • 当前可配置资源，包含一个混合结构如下：
    • 资产（静态和只读的）
    • 健康Telemetry（动态和只读的）
    • 当前可配置设置（动态和可读写的）
    • 当前进制值
  • 设置资源
    • 动态，读/写追加可配置设置
  • 服务
    • 一般化服务如事件，任务，会话
  • 注册资源
    • 静态，只读的JSON编码信息用于事件和消息注册

7.6.1 当前配置

当前可配置资源表现为当前情景下服务的知识和资源的可配置性。这可能是直接可更新的通过带有一个PATCH操作，或它是客户端只读的并且客户端必须PATCH一个分离的设置资源。

7.6.2 设置

设置资源表达的是将来状态与资源的可配置性。这个属性总是通过Redfish.Settings注解关联到一个资源。这个地方资源表现为当前状态，设置资源则表现为将来计划的状态。服务的状态会被改变，如直接或间接的执行了一个POST动作或PUT请求，或如用户在Redfish服务之外重启了机器。

7.6.3 服务

服务资源表达为Redfish服务自身的组件与依赖资源一样。只有通过遍历Redfish资源树才能发现完整的列表，这个列表包含服务信息如事件服务，任务管理以及会话管理。

7.6.4 注册

注册资源是Redfish架构定义之外的一类资源，用于协助客户端解析Redfish资源。注册的例子包括消息注册,事件注册和枚举注册，如用于BIOS的。在这些注册里面，有一个标识符用于获取更多的信息关于已提供的资源，事件，消息或其他事项。这些可以包含在其他属性，属性约束等。注册是一种自满足资源。

7.7 特殊情况下的资源处置

在某些特殊情况下会出现一些确切类型的资源，需要通过通用的语义行为来表达。

7.7.1 不存在的资源

有时候客户端请求的资源有可能不存在或者状态不可知。对于已删除的资源，这里的URI主要用于保留常量（如当一个风扇被移除时），这类资源应该表达为状态对象的情景属性如“不存在”。在这种情况下，任何被要求或被支持的属性的值都应该设置为null。

7.7.2 模式变种

当与已发布的Redfish模式出现偏差时时，模式变种是必要的。拿BIOS举个例子，在不同服务器的可用BIOS配置可能有小版本上的变化。配置的提供者可能构建一个单独的模式，它作为独立实现的超集。为了支持这些变种，Redfish支持在当前配置对象的类模式中定义缺省参数。规则如下：

  • 所有Redfish服务必须尝试在Setting Data中去设置不被支持的配置元素这样的情况，但需要在Setting Data Apply状态结构体将这些元素标记为例外，而不是让整个配置操作失败。
  • 资源中具体属性的支持需要通过当前配置对象中这个属性的界面来指示。如果这个元素在当前配置中遗漏了，客户端可以假设这个元素不被那个资源支持
  • 为了ENUM配置成员，可能要在允许的值内有一些变种，一个特殊具有只读能力的元素将被添加到当前配置用做具体的限制。

提供者可能要拆分模式资源到不同的文件中，如模式+字符串注册，每一个文件都带有一个独立的URI和不同的内容编码。

  • 如果可以采用的话，资源可能通过当前的配置对象，在发布的模式中进行缺失情况的沟通。