Redfish介绍和Postman工具使用

Redfish

Redfish的诞生是为了替代IPMI ，由于IPMI自身的局限性和安全性缺陷，IPMI 在2015年公布2.0 v1.1标准后，不再更新，被RedFish永久代替

Redfish 可扩展平台管理 API(The Redfish Scalable Platforms Management API(“Redfish”))是一种新的规范,其使用 RESTful 接口语义来访问定义在模型格式中的数据用于执行带外系统管理 (out-of-band systems management)。其适用于大规模的服务器从独立的服务器到机架式和刀片式的服务器环境，而且也同样适用于大规模的云环境。现在行业中已有几个带外系统管理标准(事实标准和法律标准)。在实现时，他们都有很大的差别。他们是针对嵌入式环境的单一服务器而开发，或基于过时的软件建模结构。当前，没有一种业界标准，既简单易用，符合新兴编程标准，易于嵌入，又能满足大型数据中心和云计算的需求。

Redfish 可扩展的平台管理 API(The Redfish Scalable Platform Management API(“Redfish”))是一个管理标准，使用数据模型表示并且包含超媒体 RESTful 接口。因为它是基于 REST，REST比其他解决方案更容易使用和实施。因为它是面向模型的,它能够表达现代系统组件之间的关系，以及服务和组件的语义。它也可以很容易地扩展。通过使用 REST 超媒体方法，Redfish 可以表达来自多个供应商的各种各样的系统。通过要求JSON 表示,各种各样的资源可以被规范化的方式创建，不仅是为了提高可扩展性,而且在大多数编程环境中负载(payload)可以很容易地被解释，以及人检查数据时有较好的相对直观性。模型是采用一个可互操作的 Redfish 模式展现,并且采用OData模式表示并可以翻译为一个JSON模式表示。并且消息的负载采用符合 0Data JSON约定的JSON 表示。将资源的 Redfish 模式定义放入一个机器可读格式的能力，允许数据与元数据之间建立关联，并且没有阻碍 Redfish服务和元数据,从而实现更高级的客户场景(例如许多数据中心和云环境)。

Redfish通过定义所有的API为RESTful形式的API来完成。REST（REpresent State Transfer，REST），这个概念从Web API而来，相对于传统的SOAP API，RESTful的API定义很简单（如：POST，GET，PUT或DELETE），将对象的状态State，用JSON或XML格式在服务器和Client之间传递，这也是它的名字的由来。

Redfish 旨在提供规范实现以下目标:

1. 可扩展(scalable)一支持云服务环境中独立机器和机架设备。
2. 灵活(flexible)一-支持当今服务中的各种各样的系统。
3. 可延展(extensible)-- 在数据模型框架内支持新的和特定厂商提供的能力
4. 向后兼容(backward compatible)一一使新功能可以被添加,同时保留规范的早期版本。
5. 互操作(interoperable)一一提供一个有用的需求基线，从而确保跨多个供应商的常见功能和实现的一致性。
6. 专注系统(system-focused)一-有效支持所需的最常见的平台硬件管理功能,从而被应用在可扩展的环境，同时也能够管理当前的服务器环境。
7. 基于标准(standards based)一一利用被广泛接受和在今天的环境中使用的协议和标准,特别是，今天被广泛采用的基于 web 客户端的编程环境。
8. 简单(simple)一一可以被软件开发人员直接使用，不需要高度专业化的编程技能或系统知识。
9. 轻量级(lightweight)-减少在管理系统上实现和验证 Redfish 服务的复杂性和成本。

设计原则

以下设计原则和技术用来帮助交付之前所述的目标和特点:

1. 提供一个使用JSON 负载和实体数据模型的 RESTful 接口
2. 从数据模型分离协议，使他们能够被独立修改
3. 指定协议和模式的版本规则。
4. 利用互联网协议标准优势，满足构建要求,比如JSON,HTTP,OData,以及本文档所引用的 RFC。
5. 集中在带外访问，可在现有 BMC 和固件产品上实现
6. 组织模式以呈现增值特性与标准化的项目
7. 使数据尽可能与上下文中的定义一样明白
8. 保持实现的灵活性。不将接口与任何特定的底层实现架构进行绑定。“规范接口而不是实现。”
9. 专注于最广泛使用的“共同特性 (common denominator)”功能。避免增加复杂性到只有一小部分用户可以使用的地址功能，。
10. 避免放置复杂性到管理控制器上，从而可以更好地支持在客户端上的操作。

Resource map

下图为DMTF组织定义的Redfish资源示意图，我们可以看到3大分支——Systems（系统的逻辑视图） 、Chassis（系统的物理视图）和 Managers（BMC功能）。

Postman

Postman 是一个用于 API 测试的工具

GET 方法用于检索资源的表示。该表示可以是一个资源或集合。服务将返回使用在Accept 头中指定的一个媒体类型的表示,从而符合媒体类型部分媒体类型的需求。如果Accept 头不存在,服务返回的资源表示为 application /json。
HTTP GET方法应当用于检索资源，并不会引起任何副作用。服务应当忽略GET的正文内容。

PATCH方法是用于执行更新已有资源的首选方法。修改资源请求在请求正文中被发送。请求中没有指定的属性不可以被PATCH请求直接改变。在更新完成后，响应或者是空，或是一个资源的表示。对某些字段实现可能基于它自己的策略而拒绝更新操作，如果是这样,实现不适用任何更新请求。
服务应当支持更新资源的PATCH方法。如果资源不能被更新，应当返回状态码405。
在任何服务器端转换后，服务可以在响应体中返回资源的表示。
如果请求中的属性不能被更新(例如当一个属性是只读时)，应当返回状态码200，以及包含指定不可更新属性声明的资源表示。在这个成功的案例中,资源中的其它属性可能被更新。
如果客户端对一个集合指定一个PATCH请求，服务应该返回状态代码405。

POST方法被用于创建一个新的资源。POST请求被提交到资源的集合，其中，新资源属于该集合。
提交一个POST请求到代表一个集合的一个资源,相当于提交相同的请求到该资源的成员属性。支持将成员添加到集合的服务应当支持两种形式。
服务应当支持POST方法用于创建资源。如果资源不提供被创建任何事物,应当返回状态码405。
创建请求的主体包含一个被创建对象的表示。服务可以忽略任何服务控制属性(例如id),强制那些属性被服务覆盖。服务应当设置位置头 (location)为新创建资源的 URI。成功创建请求的响应应该是 201(被创建),可能包括一个新创建资源表示的响应主体。

DELETE方法被用于删除一个资源。
对于可以删除的资源，服务应当支持Delete方法。如果资源不能被删除,应当返回状态码405。
在响应体中，服务可能返回一个刚刚删除的资源的表示。
对一个集合，如果客户指定一个DELETE请求，服务应该返回状态代码405。
如果资源已被删除，服务可能返回状态代码404或一个成功代码。

Postman 使用例子

查看服务器CPU信息

操作类型：
GET
https://{{deviceip}}/redfish/v1/Systems/1/Systems/1/Processors/1
请求头：
X-Auth-Token：{{X-Auth-Token}}
请求消息体：
无

添加BMC用户

操作类型：
POST
https://{{deviceip}}/redfish/v1/AccountService/Accounts
请求头：
X-Auth-Token：{{X-Auth-Token}}
Content-Type：application/json
请求消息体：
{
“UserName”:“xxxxxx”,
“Password”:“12345678”,
“RoleId”:“Administrator”,
“Enabled”: true,
“Locked”: false
}

修改用户名称

这里需要Etag
操作类型：
GET
https://{{deviceip}}/redfish/v1/AccountService/Accounts/xxxxx
请求头：
X-Auth-Token：{{X-Auth-Token}}
请求消息体：
无

操作类型：
PATCH
https://{{deviceip}}/redfish/v1/AccountService/Accounts/4
请求头：
X-Auth-Token：{{X-Auth-Token}}
Content-Type：application/json
If-Match：{{ETag}}
请求消息体：
{
“UserName” :“xxxxxxx”
}