5.概况

Redfish可扩展平台管理编程接口（“Redfish”）是一个管理标准，它使用内置于超媒体RESTful接口的数据模型展现。因为它是基于REST的，所以相比于其他的解决方案来说，Redfish更容易使用和实现。Redfish是面向模型的，所以它很适合用于表达现代系统组件之间的关系，就好像服务与组件的关系那样。另外它也很容易扩展。通过在REST中使用超媒体的方法，Redfish可以表达多个供应商之间的多种多样的系统。通过明确要求JSON的展现，各种各样的资源可以被创建成非规范化的风格，这样不仅提高了扩展性，同时有效数据可以更容易被大多数编程环境所识别，以及为人为数据检查提供相对直观的体验。该模型是通过一个可互操作的OData格式暴露出来的，通过OData JSON的约定来表达有效的JSON消息。这种格式（在XML和JSON格式下都可用）包含从注解到可自动翻译的格式到JSON格式。对于那些将资源定义为机器可读格式的外部主机来说，这种能力允许将元数据关联到真实数据而不受Redfish服务的元数据限制，因此可以应用到更多先进的客户端场景，比如很多已知的数据中心和云环境。

5.1 主要目标和范围

作为一种架构，一个协议和一种数据展现方式，Redfish有很多主要的设计原则和目标。从架构角度来说它意图支持广泛的目前已知的系统-从单机到云服务环境下的整体机架设备。可扩展性是一个关键的目标，为的是向前兼容和确定性的行为。平衡现有环境中已经被广泛接受和使用的协议与标准是达到这个目标的关键策略。尽可能的简单是另一个目标，通过在模型中创建一些必要的操作或是实例来达到这一目标。匹配现有被广泛采用的编程环境则是另一个目标。

下面是Redfish可扩展平台管理编程接口的设计原则与主要目标：

RESTful接口使用的是JSON与实体数据模型
从协议中分离出数据模型，并允许它们被单独修订
为协议与格式指定版本规则
借用因特网协议标准的优点来达到架构需求，如JSON， HTTP， OData 和本文的RFC参考
专注于可扩展环境同时也为现有服务器环境提供管理支持
专注于“带外”访问--实现在现有的BMC与固件产品上
在增加特性的同时进行标准化工作
功能必须能够被非计算机科学专业人员使用
数据定义在必要的上下文中可见
实现架构视图不可见

5.1.1 REST基础

本文定义了一个RESTful接口。很多服务应用程序是通过RESTful接口暴露的。定义一个RESTful接口主要基于几个原因：

它是一个轻量级的实现，效益是其中一个必要考量（它比SOAP具有更小的数据传输成本，比WS-Man协议具有更少的层次）
它已逐渐成为业界一种普遍的访问方式
易学易文档化
有大量的工具和开发环境可以用于REST开发
支持数据模型语义，并可以很容易映射到通用的CRUD操作
符合我们的简约化设计原则
它通样适用于软件应用程序空间正如它也适用于嵌入式环境一样，因此能够通过管理生态系统来汇聚和共享组件代码。
它是无格式的，因此能很好的适配到任何建模语言上
通过使用它，Redfish可以很好的平衡业界已有的安全与发现机制

5.1.2 符合OData约定

伴随着RESTful编程接口的流行，现有的应用几乎都拥有与其等量的RESTful接口。由于不同的设计会导致很多RESTful编程接口之间不具备互操作性，所以遵从REST模式有利于促进良好的实践。 OData定义了一个通用的RESTful约定集合，并标记为编程接口间提供互操作性的约定。在有效的JSON中采用OData来对描述模式，URL规范，命名和通用属性的结构进行规范，将不仅仅是封装RESTful编程接口的最佳实现，同时也能促进Redfish服务在生态系统中被客户端库，应用程序和工具所消费。

5.1.3 面向模型

在按位运算的解决方案里（如IPMI）很难表达关系这一属性，而面向模型却可以解决这一问题。而当前已有的模型已经过时，并变得越来越复杂同时还需要大量的IO操作来采集信息。基于这些原因，这些解决方案已经极少在实现上被关注了。其中有一些模型是起源于多个领域的（如打印机，交换机，软件等）。另外这些模型里面的元数据表现形式也只是被小范围的采用。 Redfish模型是专门为系统管理而构建的。所有的资源是以OData模式定义的，通过JSON格式来展现。OData是一个工业标准，它既是对RESTful服务封装的最佳实现，同时又能提供横跨不同类型服务进行解析的能力。JSON已经被多学科广泛的采用并且有大量的工具与编程语言可以加速开发。

5.1.4 从协议中分离数据模型

协议操作通常与数据模型是相互独立的。协议通常与数据模型的版本也是独立的。理想的情况是协议的版本变化通常是不常见的，而数据模型的版本却应该允许根据需求而改变。这就意味着创新主要发生在数据模型上而不是协议上。这就需要允许数据模型根据需求进行扩展和改变，同时又不能要求协议或是编程接口的版本也跟着改变。

5.1.5 超媒体编程接口的服务端点

如其他的超媒体编程接口一样，Redfish拥有一个单服务端点的URI，并且所有的其他资源都是通过根上的不可见URI来引用的。任何的资源发现都要通过访问根服务或者从根服务上引用过来的任何服务或资源来完成，而这一过程都将遵循根服务所支持的相同本协议版本。需要注意的是ServiceRoot模式的位置要求被放在URI路径的最后一段上，这些URI要能通过根服务来发现。

5.1.6 范围

本规格的范围是要定义下一代系统管理的接口。它包括协议和数据模型，同时还有系统管理环境中其他必要的架构组件。具体来说，本文意图使之成为一个开放的符合行业标准的解决方案，而不是一个专有的或是面向单一厂商受众的方案。它专注于为大型环境提供带外访问能力，然而这种架构也能使之成为现有多数管理标准的继任者。

5.1.7 限制

Redfish不能保证客户端软件永远不用更新。例如当有新的系统或是组件，或是数据模型更新等情况发生时很可能就需要更新客户端。对应用程序进行性能优化时通常需要进行架构调整。但是Redfish尝试通过使用格式，限制版本化和向前兼容规则，并通过分离协议与数据模型等手段来尝试将实例的强制更新降低到最少。 Redfish不会让客户端去读取一棵资源树，然后将它写入到另一个Redfish服务中。这对于一个超媒体编程接口来说这是不可能的。只有根对象拥有为外界感知的URI。资源的拓扑反射出了系统和设备的拓扑。因此不同的系统或设备类型将拥有不同形式的资源树，甚至这种情况会出现在同一厂商的系统中。另外，不是所有的Redfish资源都是易于读写的。实现可能会有其他的交互模式，这个后面讲会讨论。例如，用户认证或证书是不能被简单从一个服务里读取，然后传输给其他服务的。另外一个例子是对于读到的资源采用使用设定数据而非更改操作。标准不允许将任何原生/直通接口作为其组成部分。

5.2 服务元素

5.2.1 同步与异步操作的支持

在Redfish服务的架构里面主要的操作都是同步操作，但有些操作可能需要花费很长的时间去执行，往往会超过客户端期待的时间。由于这样的原因，服务对于某些操作必须采取谨慎的异步措施。但一个异步操作的请求部分与一个同步操作的请求部分并没有什么不同。使用HTTP的响应代码来确保客户端可以明确知道一个同步或者异步操作已经完成。更多的信息可以查看Task章节。

5.2.2 事件机制

在某些情况下服务提供一个正常的基于请求/响应范式之外的消息给客户端是很有用的。这些消息被称之为事件。当有重要的状态发生变化或者错误条件被触发时，服务以异步的方式将这些消息通知给客户端，因此这些消息往往具有时限性。

目前规范里面只定义了一种事件样式-推送式的事件。在推送式的事件里面，当服务器检查到需要发送一个事件时，它就会通过HTTP POST来推送一个消息给客户端。客户端可以在事件服务里面订阅事件来把自己放到接收列表当中，这时事件服务会为客户端创建一个ListenerDestinaton的订阅。所有的订阅都会被持久化到配置项中。

事件通常起源于一个特定的资源，但不是所有的资源都会产生事件。有能力产生事件的资源只有在被订阅之后才会生成事件。管理员或者客户端可以通过发送”订阅“消息到事件服务来进行订阅。订阅消息是通过HTTP POST方式来发送到”事件订阅集合（Event Subscriptions collection）“的。

在本规范的事件化章节中会进一步讨论事件机制的细节。

5.2.3 动作

所有的操作可以被分为两个集合：内在的（intrinsic）和外在的(extrinsic)。内在的操作常常表述为CRUD操作被映射到HTTP方法上。协议同样也有能力去支持外在的操作--这些操作不易于映射到CRUD上。外在操作的例子可能会是这样子，将元素按集合来处理可以更好的执行（为了扩展性，简化接口，服务器端语义保留或者类似的原因）或者操作不能很自然的映射到CRUD操作上。系统重置就是一个例子。有时候将多个操作组合成一个动作也是很有必要的。系统重置可以被模式化为一个状态的更新，但是从语义来讲客户端真实请求的是一个状态的变迁，并不是简单的修改状态值。

在Redfish里面，这些外在的操作都被成为动作，规范中的另外一个部分内容会对它进行细节探讨。

Redfish格式定义了通用Redfish资源上的标准行为。在这些标准动作中，Redfish格式为这些动作的行为提供了的规范语言支持。OEM扩展同样也允许被格式化，包括为已有资源上进行动作定义。

5.2.4 服务入口点发现

服务本身位于一个众所周知的URI上，同时服务主机必须能够被发现。Redfish针对UPnP协议是使用SSDP来进行发现的。SSDP被各种各样的设备所支持，如打印机。它简单，轻量，能支持IPv6并且适合在嵌入式环境中实现。Redfish也正在调查其他的入口点发现方法（如基于DHCP）。更多信息请查看发现章节。

5.2.5 远程访问支持

在架构上，Redfish支持各种各样的远程访问与重定向服务。”带外“环境中的关键支持是串口控制台访问，键盘，视频和鼠标重定向（KVM-IP），命令外壳程序（如命令行）和远程虚拟媒体。对于所有这些的支持都包含在本标准中，并通过Redfish格式来表达。本标准没有为这些设备和服务的访问来定义协议或者访问机制。Redfish格式是为这些服务的展现和配置，连接的建立以及操作状态而提供的。因此，那些协议自身的规格不在本规格的范畴之内。

5.3 安全

远程访问接口的挑战之一就是安全问题。安全的主旨是确保接口被用于Redfish交互和数据被安全的进行交换。这就意味着需要围绕接口来设计适当的安全控制机制，并保证交换数据通道的安全性。作为其中的一部分，落实到具体行为上就是对通信信道定义和使用最低级别的加密等。