サポートされていないREST Enumのユースケース
RESTサービスを利用する際、Service Studioで「enum」(列挙型)要素をインポートすることができます。Service Studioでこれらの要素は静的エンティティとして表示され、「enum」の各値は静的エンティティレコードに対応します。
Service StudioでREST APIをインポートすると、パラメータ/プロパティが、REST APIを記述するSwaggerの仕様ファイルで定義された「enum」ではなく、Textデータ型で作成される場合があります。
場合によっては、識別された制限が適用されないように、仕様ファイルを少し変更すると、OutSystemsでREST APIを効果的に利用できます。
現在サポートされていないユースケースのリストは以下のとおりです。
通常、利用するRESTサービスで「enums」がサポートされるのは、「schema」フィールド内で定義される場合や「$ref」を使用して参照される場合です。OutSystemsでは、その他の場合は現在サポートされていません。
以下のセクションでは、現在サポートされていないいくつかのユースケースに対処するためにSwaggerの仕様ファイルを調整する際の手順について説明します。
Integer型またはText型以外のEnumsまたはenumsの配列
入力パラメータ、出力パラメータ、ストラクチャアトリビュートの型は、「schema」フィールドで定義される型または「$ref」フィールドを使用して参照される型に基づいて定義されます。プラットフォームでは静的エンティティが作成され、パラメータの型として適切に参照されます。
OutSystemsでは、識別子のデータ型として複雑な型(または配列の要素の型)を定義することはできません。識別子のデータ型として定義できるのは、Integer型、Long Integer型、Text型のみです。サポートされる型以外の型のenum(またはenumの配列)がAPI仕様内にある場合、Service Studioでエラーが表示されます。
例:
"parameters": [ { "name": "RegionId", "in": "body", "schema": { "$ref": "#/definitions/Region" } } ], "definitions": { "Region": { "description": "", "type": "number", "enum": [ 56411.0, 23221.0, 11222.0, 45596.0 ] } }
"responses": { "200": { "description": "Successful request", "schema": { "type": "string", "format": "date-time", "enum": [ "2018-03-22T09:12:28Z", "2018-07-23T11:16:00Z", "2018-10-24T17:22:05Z" ] } } }
"responses": { "200": { "description": "Successful request", "schema": { "type": "array", "items": { "$ref": "#/definitions/Region" } } } } "definitions": { "Region": { "type": "string", "format": "date-time", "enum": [ "2018-03-22T09:12:28Z", "2018-03-23T09:12:28Z", "2018-03-24T09:12:28Z" ] } }
ユースケースの回避策
「enum」の型をTextに変更します。Text型は他のすべての型を受け入れることができます。ただし、OutSystemsプラットフォームではこれらの値がTextとして解釈されるため、これらの値を元の型に明示的に変換する必要がある場合があります。
一方、利用するREST APIは、これらの入力パラメータに整数または数値が含まれていることを想定しています。「OnBeforeRequest」コールバックを使用してリクエストをカスタマイズする必要があります。また、リクエスト/レスポンスをカスタマイズするロジックを定義する際は、デフォルト値を考慮してください。
参照によって指定された入力パラメータ
「parameters」セクションで定義された入力パラメータや「$ref」フィールドを使用して参照された入力パラメータは、「type」フィールドで定義された型で作成されます。静的エンティティは作成されません。ボディで定義されている場合、Service Studioは例外をスローします。
例:
"parameters": [ { "$ref": "#/parameters/RegionId" } ] "parameters": { "RegionId": { "name": "RegionId", "in": "body", "schema": { "type": "integer", "format": "int32", "enum": [ 56411, 23221, 11222, 45596 ] } } }
"parameters": [ { "$ref": "#/parameters/RegionId" } ] "parameters": { "RegionId": { "name": "RegionId", "in": "query", "type": "integer", "format": "int32", "enum": [ 56411, 23221, 11222, 45596 ] } }
ユースケースの回避策
パラメータを参照する代わりに適切に定義します。
ヘッダーで指定された出力パラメータ
「headers」セクションで定義された出力パラメータは、「type」フィールドで定義された型で作成されます。静的エンティティは作成されません。
例:
"responses": { "200": { "description": "Successful request", "headers": { "RegionId": { "type": "integer", "format": "int64", "enum": [ 56411, 23221, 11222, 45596 ] } } } }
"responses": { "200": { "$ref": "#/responses/DefaultSuccessResponse" } } "responses": { "DefaultSuccessResponse": { "description": "Successful request", "headers": { "RegionId": { "type": "integer", "format": "int32", "enum": [ 56411, 23221, 11222, 45596 ] } } } }
ユースケースの回避策
現在、こうしたサポートされていないユースケースに対処するための一般的な回避策はありません。
oneOfキーワードを使用する変数の型
仕様の要素で、oneOf
キーワードを使用して複数の型を定義できるものは、現在サポートされていません。この場合、OutSystemsは以下のルールに従って要素の特定の型を判定します。
oneOf
定義にオブジェクト(複雑な型)エントリが1つだけ含まれる場合は、そのオブジェクトが型として選択されます。- オブジェクトが複数あるか、またはオブジェクトがない場合は、
string
エントリが検索されます。エントリが1つ以上見つかった場合、最初に見つかったstring
エントリが型として使用されます。 - 上記のいずれのルールも当てはまらない場合は、
oneOf
定義の最初のエントリが型として使用されます。
上記のルールに従って自動的に型が設定されます。ただし、その後RESTサービスをインポートしてから型を変更することができます。
ユースケースの回避策
サービスをインポートするときに自動的に定義される型をカスタマイズする以外に、こうしたサポートされていないユースケースに対処するための一般的な回避策はありません。