私は、応答タイプを記述するためにswaggerの構文に苦労しています。私がモデル化しようとしているのは、動的なキーと値を持つハッシュマップです。これは、ローカライズを可能にするために必要です。言語は異なる場合がありますが、英語を常に提供する必要があります。
JSONでの応答は次のようになります。
{
id: "1234",
name: {
en: "english text",
de: "Deutscher Text"
}
}
私の最初の試みはそのように見えましたが、名前の一部を書く方法がわかりません。 AdditionalPropertiesはキーのようですが、頭を包むことはできません。また、この構文では英語のテキストの要件が謎であり、この例も期待どおりに機能しないようです。 UIで空の$ folded:を生成します。
delayReason:
type: object
properties:
id:
type: string
description: Identifier for a delay reason.
name:
type: object
additionalProperties:
type: string
required: [id, name]
example:
id: 123
name:
en: english text
de: Deutscher Text
これには、結果がキーとして言語コードを持ち、ハッシュマップの値としてテキストを持つという手掛かりもありません。
少なくとも3つの個別のバグや制限に直面しているようです。
Swagger-EditorもSwagger-UIも、additionalProperties
がオブジェクトスキーマで許可されていることを示すドキュメント形式の表示を提供しません。したがって、additionalProperties
を正しく使用し、Swaggerパーサーによって認識された場合でも、これらのドキュメント形式では表示されません。この詳細をスキーマdescription
に追加する必要があるため、ユーザーは追加の文字列プロパティを含めることができることを理解します。
注:追加のプロパティ名は、慣例に従うことを期待するでしょう。 2文字の言語コード。完全なJSONスキーマではpatternProperties
でこれを指定できますが、残念ながらSwaggerのスキーマオブジェクトではサポートされていません。そのため、スキーマの説明でそれを指定する必要があります。
Swagger-Editor形式では、この奇妙な「folded:」プロパティが表示される場合があります。今朝見ましたが、今では奇妙に再現できません。今日は修正プログラムが適用された可能性があります。ただし、それは確かにバグであり、Swagger-Editorに固有のものです。ダウンストリームのコード生成や、実行時にクライアント開発者にAPIドキュメントを提示する標準のSwagger-UIに影響することはありません。 (Swagger-EditorのドキュメントペインはSwagger-UIに似ていますが、別個の実装です。)
SwaggerでのadditionalProperties
の使用には、わずかではありますが重要な制限があります。 Helen の例では目に見えるエラーは表示されませんが、実際にはSwaggerパーサーはこのスキーマを正しく処理できません。明示的に宣言されたen
プロパティを無視するか、additionalProperties
!を無視します。
この最後の問題は、Swagger Javaスタック(Swagger-Codegenを含む)全体で使用されるコアコンポーネントの1つです。特定のコンテキストで定義されたスキーマがproperties
とadditionalProperties
の組み合わせですが、他のコンテキストで定義されたスキーマはできません。
良いニュース:小さな調整で、Helenの例を正しく動作させることができます。ネストされたオブジェクトスキーマを独自のトップレベル定義に抽出するだけです。 LocalizedName
と呼びます:
definitions:
delayReason:
type: object
properties:
id:
type: string
description: Identifier for a delay reason.
name:
$ref: "#/definitions/LocalizedName"
required: [id, name]
example:
id: '123' # Note the quotes to force the value as a string
name:
en: English text
de: Deutscher Text
LocalizedName:
type: object
description: A hashmap with language code as a key and the text as the value.
properties:
en:
type: string
description: English text of a delay reason.
required: [en]
additionalProperties:
type: string
additionalProperties
の使用は正しく、モデルは正しいです。
Swagger/OpenAPIでは、ハッシュマップキーは文字列であると想定されているため、キータイプは明示的に定義されていません。 additionalProperties
は、ハッシュマップ値のタイプを定義します。したがって、このスキーマ
type: object
additionalProperties:
type: string
次のような文字列から文字列へのマップを定義します。
{
"en": "English text",
"de": "Deutscher Text"
}
次のような文字列から整数へのマップが必要な場合:
{
"en": 5,
"de": 3
}
additionalProperties
を値型integer
として定義します:
type: object
additionalProperties:
type: integer
en
をハッシュマップの必須キーとして定義するには:
type: object
properties:
en:
type: string
required: [en]
additionalProperties:
type: string
definitions:
delayReason:
type: object
properties:
id:
type: string
description: Identifier for a delay reason.
name:
type: object
description: A hashmap with language code as a key and the text as the value.
properties:
en:
type: string
description: English text of a delay reason.
required: [en]
additionalProperties:
type: string
required: [id, name]
example:
id: '123' # Note the quotes to force the value as a string
name:
en: English text
de: Deutscher Text
これには、結果がキーとして言語コードを持ち、ハッシュマップの値としてテキストを持つという手掛かりもありません。
そのようなことは、description
で口頭で文書化できます。
また、この例は期待どおりに機能しないようです。 UIで空の$ folded:を生成します。
元の仕様に問題があったかどうかはわかりませんが、上記の仕様は有効で、 Swagger Editor で正常に見えます。
ダイナミックキーを使用する代わりに、まだ設計段階にいる場合は、次のような構造を持つ配列内の他のすべての言語参照をプッシュできます。
{
"launguage":"en"
"text":"Hello World"
}
それは物事を非常に単純化し、additionalProperties
に依存していないので、生成されたクライアントライブラリはこれを消化するのがより簡単だとわかります。