Redfishの開発者によると、現在使用されているプロトコルはすでに時代遅れであり、最新のIT機器を管理する可能性を完全に明らかにすることはできません。 IPMIは、Intel、Dell、NEC、Hewlett-Packardのサポートにより1998年に初めて導入されました。 当時、サーバーは依然として8ビットマイクロコントローラーによって制御されていたため、開発段階でプロトコルが大幅に制限されていました。 2004年に、プロトコルはバージョン2.0に更新されました。 IPMI 2.0で導入された主な改善点には、新しい認証および暗号化アルゴリズム、新しいSerial Over LAN機能（アプリケーション、BIOS、およびオペレーティングシステムとのリモート相互作用をサポート）、組み込みファイアウォール、新しい構成およびユーザー登録オプションが含まれます。 サイバー犯罪者向けのIPMIは、オペレーティングシステムツールを必要としないサーバーへの低レベルアクセスツールを入手する絶好の機会です。 セキュリティの問題は、多くのIPMI構成がパスワードなしで利用できるか、デフォルトのパスワードを使用するという事実によって悪化します。
さらに、専門家は、パスワードは明確な形式で保存され、特定の種類のIPMIトラフィックの暗号化はなく、単一のパスワードの漏洩はグループ内のすべてのサーバーへのフルアクセスを意味することに注意しました。
これらの理由は、システム管理とセキュリティの両方の点で最新の要件を満たす新しいプロトコルを作成する主な理由です。
Redfish開発者は、アーキテクチャ、プロトコル、およびデータ表現モデルの開発においてさまざまな課題に直面しています。 このアーキテクチャは、スタンドアロンのマシンからクラウドで使用される機器ラックに至るまで、現在稼働中の幅広いシステムをサポートすると想定されています。 Redfishのもう1つの目標は、可能な限りシンプルであることです。 今日広く受け入れられているプログラミング環境への準拠も重要な原則の1つです。
Redfishの設計で定められた他の原則の中で：
1）JSONデータモデルを使用したRESTfulインターフェイス。
2）プロトコルとデータモデルが分離されているため、互いに別々に更新できます。
3）プロトコルおよびスキームのバージョンを指定するための特別なルール。
4）JSON、HTTP、RFCなどのアーキテクチャ要件に直面しているインターネットプロトコルの標準の弱点を排除します。
5）プロトコルはスケーラブルな環境に焦点を合わせていますが、現在のサーバー環境を管理できます。
6）帯域外に焦点を当てる-BMCおよびファームウェア製品で実現可能。
7）機能は、平均的なユーザーにとってアクセス可能/理解可能でなければなりません。
8）アーキテクチャの実装は、セキュリティの観点から可能な限り慎重でなければなりません。
RESTfulを使用する主な理由：
1）保存が重要な場合（SOAPよりもデータ転送が少なく、WS-Manよりもプロトコル層が少ない）に簡単に実装できます。
2）業界で最も一般的なアクセス方法になることを目指しています。
3）学習しやすい、ドキュメントのアクセシビリティ。
4）RESTに使用できる既製のツールと開発環境が多数あります。
5）RAMおよびCPUの消費量は、他のインターフェイスの消費量よりも少ない。
6）データモデルのセマンティクスと一般的なCRUD操作の単純なマッピングをサポートします。
7）開発原則に準拠：使いやすさ。
8）組み込み環境とアプリケーション空間の両方で等しく使用できるため、管理エコシステム内のコンポーネントのコードをまとめることができます。
9）最初は回路に結び付けられていないため、どのモデリング言語にも適合します。
10）そのおかげで、Redfishは業界のメカニズムを安全に開始するために使用できます。
データモデルからのプロトコルの分離
プロトコルのバージョンはほとんど変更されませんが、データモデルのバージョンは必要に応じて変更できます。 したがって、プロトコルではなくデータモデルの革新が最初に期待されています。 これにより、APIまたはプロトコルのバージョンに触れることなく、必要に応じてデータモデルを変更できます。
ジョンソン
すべてのリソースはJSON形式で表現できます。 JSONスキーマは、クラスを定義するために使用および拡張されます。 JSONとJSONスキーマは両方とも広く使用されており、開発を加速するさまざまなプログラミング言語用の多数のツールを備えています。
同期および非同期操作のサポート
このアーキテクチャのほとんどの操作は同期的に実行できますが、一部の操作は、クライアントが待機することに同意するよりも長い時間がかかる場合があります。 このため、一部の操作はサービスの裁量で非同期になる場合があります。 非同期操作要求は、同期要求と違いはありません。
HTTP応答コードを使用すると、クライアントは操作が完了したかどうかを同期的または非同期的に判断できます。
アクション
操作は、内部と外部の2つのタイプに分類できます。 このプロトコルには、外部操作（CRUDに自由に表示されない操作）をサポートする機能があります。 例は、ソフトウェアの更新またはシステムのリセットです。 ソフトウェアの更新は、3つの可能な操作と見なされます。更新のためのイメージのシステムへの転送、システムによるイメージのダウンロード、およびその後のアクティベーションです。 これらの操作を1つのアクションまたは1つの関数呼び出しに結合することができます。
Redfishでは、これらの外部操作はアクションと呼ばれます。 Redfishスキーマには、各リソースを記述する特定のアクションが定義されています。 これらの標準アクションのために、Redfishスキーマには規制言語が用意されています。 OEM拡張もスキーマで許可され、アクションに割り当てられます。
デバイスサポート（コンソール、KVM-IP、コマンドシェル、仮想メディア）
このアーキテクチャは、さまざまなデバイスとサービスをサポートしています。 非常に重要なコンポーネントは、コンソール（KVM-IP）、コマンドシェル（Linuxコマンドラインなど）、およびリモート仮想メディアのサポートメカニズムです。 それらのサポートはこの標準で実装され、データモデルの表現レベルで図に表されますが、プロトコル自体はこの標準の範囲を超えています。
プログラム可能なリモートインターフェイスのセキュリティ問題は、送信されたデータの保護だけでなく、Redfishとの対話に使用されるインターフェイス自体の保護も提供することです。 これは、インターフェイスレベルでの適切なセキュリティ制御メカニズムの開発とデータ交換チャネルの保護を意味します。
安全性
実装では、TLS v1.1以降をサポートし、互換性のあるTLS接続のみを使用して機密データを転送する必要があります。
実装は、TLSに基づくAES-256をサポートする必要があります。 Redfishは、信頼できる証明書を使用せずに認証と識別を含む暗号のサポートを検討する必要があります：TLS_PSK_WITH_AES_256_GCM_SHA384、TLS_DHE_PSK_WITH_AES_256_GCM_SHA384、TLS_RSA_PSK_WITH_AES_256_GCM。
AES-GCMは効率的かつ安全であるだけでなく、そのハードウェア実装は低コストと遅延で高速を実現できます。
実装では、少なくとも4096ビットのRSAキーとRSA-SHA512署名を含む証明書を使用して、デフォルトの証明書の置換をサポートする必要があります。
レッドフィッシュの特徴
1）監視と管理のための特権モデル。
2）システム設定。
3）BIOS設定。
4）電源管理システム。
5）情報センサー（電力/熱/実行可能性）;
6）ネットワーク設定。
7）メモリ設定。
8）ジャーナリング。
9）Redfish設定サービス。
10）アカウント管理。
11）ファームウェアバージョン。
12）インフラストラクチャ内の認証。
13）CURLとの互換性。
14）顧客の自動化。
15）組み込みのサービスプロセス。
開発者によると、Redfishには1つのシステムだけでなく、棚システム全体を管理する機能があります。 また、Redfishは一種のIPMIの生まれ変わりです。つまり、新しいシステムに切り替えても、ユーザーはIPMIが好きな機能を失うことはありません。 追加のチャネルを介した管理により、OSの動作容量に関係なくメンテナンスを実行できます。 BIOS / UEFI設定の監視または変更、およびシステムレベル（温度、電圧、ファン、電源）の統計の制御に使用できます。 作成者による最新の声明によれば、この標準は開発中であり、業界標準による分析のために間もなく提出されます。