API Caller 機能概要
- Haruhide Yasukawa (Unlicensed)
概要
API Callerとは?
API Caller は、レガシーアプリケーションから RESTful API を呼出すことができます。概要:
デザインタイム（設計時間）とランタイム（実行時間）の２つのフェーズに分かれています。
デザインタイム（設計時間） フェーズ
ユーザは、APIの仕様をインポートし、編集します
システムはSwagger仕様からエンドポイント定義メタデータを生成します
ユーザはエンドポイント定義メタデータを編集します
ユーザはエンドポイント定義メタデータから生成される標準レガシファイル(例. Cobol Copybooks ファイル をダウンロードします
ランタイム（実行時間） フェーズ
レガシープログラムは、生成されたCOBOL Copybook コード（デザインタイムフェーズで説明）を利用し、APIを呼出します
コードは、RESTful リクエスト/レスポンスのプロキシとしてAPI Callerを利用します
レガシープログラムは、バッファをAPI Callerに転送し、API CallerはそれをAPIへのREST リクエストに変換し、レスポンスを受信します
API Callerは、レスポンスをバッファーに変換し、レガシープログラムに転送します。
システムは保護されており、認証が必要です。ユーザーは、アプリケーションの内部ユーザーベースで管理されます。
*「エンドポイント」という用語は、API仕様から生成され、API Callerアプリケーションで管理されるAPI仕様定義メタデータを表すために使用されることに注意してください。
デザイン
ランタイム
テクニカル概要
デザインタイム（設計時間）フロー
ユーザはAPI Callerアプリケーションに移動し、仕様エディターを使用してエンドポイント/デザインAPIでアクションを実行します
ユーザのリクエストがデザイナーコンポーネントに送信されます
アクションにデータベースが使用されない場合、リクエストは設計者自身によって処理されます。
アクションにデータベースが使用される場合–設計者はさらに注意を払うためにプロキシコンポーネントにリクエストを送信します
プロキシは、ユーザのリクエストされたアクションに従ってデータベースを取得/更新します
プロキシは、アクションが成功したかどうかに基づいて、データベースからack / failureを受信します
プロキシはレスポンスをデザイナコンポーネントに送り返します
設計者はアプリケーションにレスポンスを送り返します
レスポンスがユーザに表示され、ユーザーは作業を続行します。
ユーザは、選択したエンドポイントからクライアントを生成することを決定します
ユーザはプロキシクライアントをレガシーバックエンドにデプロイします
レガシーバックエンドは、デプロイメントプロキシクライアントに基づいてバッファリクエストをコン
バータコンポーネントに送信し、APIサービスを呼び出します
コンバーターはバッファーをHTTPリクエストモデルに変換し、送信機/呼び出し元に送信します。
送信者/呼び出し元は、APIサービスを呼び出すためにHTTPレスポンスを送信します。
APIサービスは、HTTPレスポンスを送信者/呼び出し元に送り返します。
送信者/発信者はHTTPレスポンスをコンバーターに送り返します。
コンバーターはHTTPレスポンスをバッファーに変換し、レガシーバックエンドに送り返します。
レガシーバックエンドはレスポンスを処理し、その作業を続行します。
ランタイム（実行時間） (プロキシProxy) フロー
レガシーバックエンドのプログラムは、リクエストで提供されたプロキシクライアントのデータを使用して、API Callerプロキシへのリクエストを開始します
コンバータは、レガシーバックエンドからバッファーを受信し、それをHTTPリクエストに変換して、トランスミッター/Callerに送信します
トランスミッター/Callerは、HTTPリクエストをサードパーティのAPIサービスに送信します。
APIはHTTPレスポンスで応答します
トランスミッター/Callerは、レスポンスをコンバーターに戻します。
コンバータは、レスポンスをレガシーバックエンド側のクライアントプロキシに適合するバッファーに変換し直し、レガシーバックエンドに送り返します。
機能制限
API Caller API 認証
現在、ベーシック認証がサポートされています
API Caller OpenAPI Swagger パーサー
API Caller Swaggerパーサーは、次のユーティリティと機能をサポートしています:
OpenAPIParser.readContentを使用して、SwaggerV3仕様ファイルを解析します
SwaggerConvertorを使用して、Swagger V2のコンテンツを読み取り、V3に変換します。
どちらのライブラリもSwaggerV3のものです
V3仕様ファイルの場合、「isResolve」のparse-optionsを使用します（「component」セクションのすべての仕様ファイル参照を統合します。「component」セクションはOpenAPIモデルの一部です）。
V2仕様ファイルの場合、「isResolveFully」解析オプションを使用して、参照名を「definition」セクションから「component」セクションに変更します（「definition」セクションの目的は「components」セクションと同じですが、 V2にのみ使用されます）
readLocationは相対参照（同じパス内のファイルを指す参照）をサポートしますが、より大きな仕様ファイルでGradleクリーンビルドを渡しません。代わりに「readContent」関数を使用しますが、この関数は相対参照を読み取ることができません。
YAMLファイルとJSONファイルの解析をサポートしています
V2およびV3仕様ファイルの解析をサポートしています。 V1はサポートされていないことに注意してください
各仕様ファイルには、APIサーバーとベースURLを指定する「サーバー」セクションがあります。複数のサーバーを定義できますが、現在サポートしているのは1つだけです。最初はHTTPSプロトコルで始まるサーバーを検索しますが、見つからない場合は、HTTPプロトコルで始まるサーバーをベースURLとして選択します。
グローバルな「コンポーネント」セクションは、特定のAPIで使用される一般的なデータ構造を定義します。これらは、パラメーター/リクエストの本文と応答の$ refを介して参照できます。私たちはそれらすべてをサポートします。
現在、相対参照とリモート参照の参照はサポートされていません
基本認証がサポートされています
異なるパス/または同じパスに独自のサーバーのセクションを使用する操作が複数ある場合は、ベースパスのURLをオーバーライドする場合をサポートします。これは、一部のエンドポイントが他のAPIとは異なるサーバーまたはベースパスを使用する場合に役立ちます。段落8で説明したように、最初にHTTPSスキーマを使用するURLを見つけるかどうかを確認します。それ以外の場合は、HTTPスキーマをデフォルトとして使用するサーバーを提供します。
ベースパスがまったくない場合は、ベースパスとして「/」文字を指定するだけです。
現在、消費（コンシューミング）と生成（プロデューシング）の両方でアプリケーション/ JSONメディアタイプのみをサポートしています。指定された仕様ファイルにJSONメディアタイプがない場合、特定の操作（サポートされていないメディアタイプを使用する操作）をHttpEndpointsのマップに挿入せず、適切なメッセージをログに記録します。仕様でメディアタイプがまったく指定されていない場合は、JSONメディアタイプを使用してデフォルトで消費および生成します。
すべてのパラメータータイプ（body、header、cookie、path、query）をサポートします。Cookieとヘッダーパラメーターは文字列データ型に変換されます。
Cookieは、HttpEndpointモデルのヘッダーリストの一部として表示されます。
パラメータを必須としてマークするための「required」キーワードをサポートしています（キーワードが仕様で常に提供されているとは限りませんが、パスパラメータは常に必須としてマークされます）。
配列およびオブジェクトパラメーター（styleおよびexplodeキーワード）のデフォルトのシリアル化メソッドをサポートします:
パスパラメータスタイルの場合：simple、explode false
クエリパラメータスタイルの場合：form、explode true
ヘッダーパラメータスタイルの場合：simple、explode false
cookieパラメータスタイルの場合：form、explode true
上記のリストに表示されていないその他のシリアル化はサポートされていません。 さらに、この特定のシリアル化タイプのパラメーターを含む操作全体は、HttpEndpointsのマップに挿入されません。
デフォルトのパラメータ値をサポートします（提供されている場合）
パラメータのレベルに使用されるキーワード「nullable」、「allowEmptyValue」、「deprecated」はサポートされていません。
操作レベルではなくパスレベルで宣言されているパラメーターもサポートされていません
OpenAPI 3.0には、スキーマを組み合わせるために使用できるいくつかのキーワードが用意されています:
oneOf –サブスキーマの1つに対して値を検証します。
allOf –すべてのサブスキーマに対して値を検証します。
anyOf –1つ以上のサブスキーマに対して値を検証します。
前の段落の続きとして、現在のバージョンでは、すべてのキーワードを「allOf」として関連付け、APIで指定されているようにユーザーがモデルを適切に処理する必要があるというメッセージを提供します。
レスポンスセクションでは、各レスポンスはHTTPステータスコードで始まります。 数字（例：200）で始まる場合は、そのまま保存します。 保存された単語「default」を使用する場合は、「-1」として保存します。 一般的なステータスコードが含まれている場合（例： 5XX）、500として保存します
応答ヘッダーは文字列として保存されます
文字列、数値、整数、ブール、列挙型、オブジェクト、および配列のデータ型はサポートされていますが、「混合型」として定義されたパラメーターはサポートされていません。
最小および最大のキーワードがサポートされています。
「multipleOf」キーワード（数値が別の数値の倍数でなければならないことを指定）はサポートされていません
文字列でサポートされている形式= [日付、日時]および文字列でサポートされていない形式= [パスワード、バイト、バイナリ、電子メール、UUID、URI、ホスト名、ipv4、ipv6]
文字列の「パターン」キーワードもサポートされていません
配列のデータ型-uniqueitems（配列内のすべての項目が一意である必要があることを指定するキーワード）はサポートされていません
「Required」キーワードは、必須パラメーター名のリスト[“ name”、“ id”]またはブール値[“ true”、“ false”]として表すことができます。両方のオプションをサポートします
ReadOnlyプロパティはレスポンスに含まれていますが、特別な処理はありません（readOnlyとしてマークされたリクエストのパラメーターの場合、GETによって返されますが、POST / PUT / PATCHでは使用されません）
同じことがWriteOnlyプロパティ（リクエストに表示される）にも当てはまります。リクエストのパラメータがwriteOnlyとしてマークされている場合、それはPOST、PUT、PATCHで使用されているが、GETによって返されていないことを意味します。特別な扱いもしていません
ネストされたオブジェクトがサポートされています（タイプオブジェクトのパラメーター内のタイプオブジェクトのパラメーターなど）
AnyValue-どのデータ型にも一致する型のないスキーマはサポートされていません
例/コールバック/リンク/認証およびタグのセクションは、現在のバージョンの範囲外です