パラメータの記述
Swagger では、API 操作パラメーターは操作定義の parameters
セクションで定義されます。各パラメーターには name
、値の type
(プリミティブ値パラメーターの場合) または schema
(リクエストボディの場合)、およびオプションの description
があります。以下に例を示します。
1paths:2 /users/{userId}:3 get:4 summary: Gets a user by ID.5 parameters:6 - in: path7 name: userId8 type: integer9 required: true10 description: Numeric ID of the user to get.
parameters
は配列であるため、YAML では各パラメーター定義の前にダッシュ (-
) を付けてリストする必要があります。
パラメーターの種類
Swagger は、パラメーターの場所に基づいて、以下のパラメータータイプを区別します。場所はパラメーターの in
キーによって決定されます。例えば、in: query
や in: path
です。
- クエリパラメーター(例:
/users?role=admin
) - パスパラメーター(例:
/users/{id}
) - ヘッダーパラメーター(例:
X-MyHeader: Value
) - POST、PUT、PATCH リクエストのボディを記述するボディパラメーター(リクエストボディの記述を参照)
- フォームパラメーター –
Content-Type
がapplication/x-www-form-urlencoded
およびmultipart/form-data
(後者は通常ファイルアップロードに使用されます)のリクエストのペイロードを記述するために使用されるさまざまなボディパラメーター
クエリパラメータ
クエリパラメーターは最も一般的なパラメータータイプです。リクエスト URL の末尾に疑問符 (?
) の後に現れ、異なる name=value
ペアはアンパサンド (&
) で区切られます。クエリパラメーターは必須にもオプションにもなり得ます。
1GET /pets/findByStatus?status=available2GET /notes?offset=100&limit=50
クエリパラメーターを示すには、in: query
を使用します。
1parameters:2 - in: query3 name: offset4 type: integer5 description: The number of items to skip before starting to collect the result set.6 - in: query7 name: limit8 type: integer9 description: The numbers of items to return.
クエリパラメーターはプリミティブ型のみをサポートします。array
を持つことはできますが、items
はプリミティブ値型でなければなりません。オブジェクトはサポートされていません。
注: クエリパラメーターとして渡される API キーを記述するには、代わりにセキュリティ定義を使用します。API キーを参照してください。
パスパラメータ
パスパラメータは、変化する可能性のある URL パスの一部です。通常、ID で識別されるユーザーなど、コレクション内の特定の¹リソースを指すために使用されます。URL には複数のパスパラメータを持つことができ、それぞれ中括弧 { }
で示されます。
1GET /users/{id}2GET /cars/{carId}/drivers/{driverId}
クライアントがAPIコールを行う際、各パスパラメータは実際の値に置き換えられる必要があります。Swaggerでは、パスパラメータは in: path
と必要に応じて他の属性を使用して定義されます。パラメータ名はパスで指定されたものと同じである必要があります。また、パスパラメータは常に必須であるため、required: true
を追加することを忘れないでください。以下は GET /users/{id}
の例です。
1paths:2 /users/{id}:3 get:4 parameters:5 - in: path6 name: id # Note the name is the same as in the path7 required: true8 type: integer9 minimum: 110 description: The user ID.11 responses:12 200:13 description: OK
パスパラメーターは、GET /users/12,34,56
のように複数値にすることができます。これは、パラメーターの型を array
として指定することで実現されます。以下の配列と複数値パラメーターを参照してください。
ヘッダーパラメータ
API 呼び出しでは、HTTP リクエストとともにカスタムヘッダーを送信する必要がある場合があります。Swagger では、カスタムリクエストヘッダーを in: header
パラメーターとして定義できます。たとえば、GET /ping
への呼び出しで X-Request-ID
ヘッダーが必要な場合を考えます。
1GET /ping HTTP/1.12Host: example.com3X-Request-ID: 77e1c83b-7bb0-437b-bc50-a7a58e5660ac
Swagger では、この操作を次のように定義します。
1paths:2 /ping:3 get:4 summary: Checks if the server is alive.5 parameters:6 - in: header7 name: X-Request-ID8 type: string9 required: true
同様の方法で、カスタムレスポンスヘッダーを定義できます。
注: Swagger 仕様には、一部のヘッダーに特別なキーワードがあります。
ヘッダー | Swagger キーワード | 詳細については... |
---|---|---|
コンテンツタイプ |
consumes (リクエストコンテンツタイプ)produces (レスポンスコンテンツタイプ) |
MIME タイプ |
承諾 |
produces |
MIME タイプ |
認証 |
securityDefinitions , security |
認証 |
フォームパラメーター
フォームパラメーターは、Content-Type
が以下のリクエストのペイロードを記述するために使用されます。
application/x-www-form-urlencoded
(プリミティブ値およびプリミティブ値の配列を POST するために使用されます)。multipart/form-data
(ファイルのアップロード、またはファイルとプリミティブデータの組み合わせのために使用されます)。
つまり、操作の consumes
プロパティはこれらのコンテンツタイプの一つを指定する必要があります。フォームパラメーターは in: formData
として定義されます。これらはプリミティブ (文字列、数値、ブール値) またはプリミティブの配列のみにすることができます (つまり、items
の値として $ref
を使用することはできません)。また、formData
はボディを記述する特定の方法であるため、フォームパラメーターは in: body
パラメーターと共存することはできません。フォームパラメーターを説明するために、HTML の POST フォームを考えてみましょう。
1<form action="http://example.com/survey" method="post">2 <input type="text" name="name" />3 <input type="number" name="fav_number" />4 <input type="submit" />5</form>
このフォームはデータをフォームのエンドポイントに POST します。
1POST /survey HTTP/1.12Host: example.com3Content-Type: application/x-www-form-urlencoded4Content-Length: 295
6name=Amy+Smith&fav_number=321
Swagger では、エンドポイントを次のように記述できます。
1paths:2 /survey:3 post:4 summary: A sample survey.5 consumes:6 - application/x-www-form-urlencoded7 parameters:8 - in: formData9 name: name10 type: string11 description: A person's name.12 - in: formData13 name: fav_number14 type: number15 description: A person's favorite number.16 responses:17 200:18 description: OK
ファイルアップロード用のフォームパラメーターの定義方法については、ファイルアップロードを参照してください。
必須パラメーターとオプションパラメーター
デフォルトでは、Swagger はすべてのリクエストパラメーターをオプションとして扱います。パラメーターを必須としてマークするには、required: true
を追加できます。パスパラメーターは常に必須であるため、required: true
を持つ必要があることに注意してください。
1parameters:2 - in: path3 name: userId4 type: integer5 required: true # <----------6 description: Numeric ID of the user to get.
デフォルトパラメーター値
オプションのパラメーターのデフォルト値を指定するには、default
キーを使用できます。デフォルト値は、クライアントがリクエストでパラメーター値を指定しない場合にサーバーが使用する値です。値の型は、パラメーターのデータ型と同じでなければなりません。典型的な例は、オフセットとリミットのようなページングパラメーターです。
1GET /users2GET /users?offset=30&limit=10
オフセットがデフォルトで 0、リミットがデフォルトで 20 で、範囲が 0 から 100 であると仮定すると、これらのパラメーターは次のように定義されます。
1parameters:2 - in: query3 name: offset4 type: integer5 required: false6 default: 07 minimum: 08 description: The number of items to skip before starting to collect the result set.9 - in: query10 name: limit11 type: integer12 required: false13 default: 2014 minimum: 115 maximum: 10016 description: The numbers of items to return.
よくある間違い
default
キーワードを使用する際には、2つのよくある間違いがあります。
default
を必須パラメーターまたはプロパティ(例:パスパラメーター)と一緒に使用すること。これは意味がありません。値が必須である場合、クライアントは常にそれを送信する必要があり、デフォルト値は決して使用されません。default
をサンプル値を指定するために使用すること。これはデフォルトの意図された用途ではなく、一部の Swagger ツールで予期しない動作につながる可能性があります。この目的のために、仕様の一部の要素はexample
またはexamples
キーワードをサポートしています。
Enum パラメーター
enum
キーワードを使用すると、パラメータ値を固定値のセットに制限できます。enum 値はパラメータの type
と同じ型でなければなりません。
1- in: query2 name: status3 type: string4 enum: [available, pending, sold]
詳細情報: Enum の定義
配列と複数値パラメーター
パス、クエリ、ヘッダー、およびフォームパラメーターは、たとえば次のような値のリストを受け入れることができます。
1GET /users/12,34,56,782GET /resource?param=value1,value2,value33GET /resource?param=value1¶m=value2¶m=value34
5POST /resource6param=value1¶m=value2
複数値パラメーターは、type: array
と適切な collectionFormat
で定義する必要があります。
1# color=red,black,white2parameters:3 - in: query4 name: color5 type: array6 collectionFormat: csv7 items:8 type: string
collectionFormat
は、配列のフォーマット (複数のパラメーターを持つ単一のパラメーター、または同じ名前を持つ複数のパラメーター) および配列項目の区切り文字を指定します。
コレクション形式 | 説明 | 例 |
---|---|---|
csv (デフォルト) |
カンマ区切り値。 | foo,bar,baz |
ssv |
スペース区切りの値。 | foo bar baz |
tsv |
タブ区切りの値。 | "foo\tbar\tbaz" |
パイプ |
パイプ区切りの値。 | foo|bar|baz |
マルチ |
複数値ではなく、複数のパラメーターインスタンス。これは in: query と in: formData のパラメーターのみでサポートされます。 |
foo=value&foo=another_value |
さらに、次のこともできます。
minItems
とmaxItems
を使用して配列のサイズを制御するuniqueItems
を強制する- 配列アイテムを固定された
enum
値のセットに制限する。
例えば
1- in: query2 name: color3 required: false4 type: array5 minItems: 16 maxItems: 57 uniqueItems: true8 items:9 type: string10 enum:11 [12 black,13 white,14 gray,15 red,16 pink,17 orange,18 yellow,19 green,20 blue,21 purple,22 brown,23 ]
また、このパラメーターが省略された場合にサーバーが使用するデフォルトの配列を指定することもできます。
1- in: query2 name: sort3 required: false4 type: array5 items:6 type: string7 default: ["-modified", "+id"]
定数パラメーター
単一の可能な値を持つ必須パラメーターとして、定数パラメーターを定義できます。
1- required: true2 enum: [value]
enum
プロパティは、可能な値を指定します。この例では、1つの値のみが使用でき、これがユーザーが選択できる Swagger UI で唯一の利用可能な値になります。
注: 定数パラメーターは、デフォルトパラメーター値と同じではありません。定数パラメーターはクライアントによって常に送信されますが、デフォルト値は、パラメーターがクライアントによって送信されない場合にサーバーが使用するものです。
値のないパラメーター
クエリ文字列とフォームデータパラメーターは、名前のみで値を持たない場合があります。
1GET /foo?metadata2
3POST /something4foo&bar&baz
そのようなパラメータを記述するには、allowEmptyValue
を使用します。
1- in: query2 name: metadata3 required: true4 type: boolean5 allowEmptyValue: true # <-----
共通パラメーター
パスのすべてのメソッドの共通パラメーター
パラメータはパス自体で定義できます。この場合、パラメータはこのパスの下で記述されたすべての操作に存在します。典型的な例は、パスパラメータを介してアクセスされる同じリソースを操作する GET/PUT/PATCH/DELETE 操作です。
1paths:2 /user/{id}:3 parameters:4 - in: path5 name: id6 type: integer7 required: true8 description: The user ID.9
10 get:11 summary: Gets a user by ID.12 ...13 patch:14 summary: Updates an existing user with the specified ID.15 ...16 delete:17 summary: Deletes the user with the specified ID.18 ...
操作レベルで定義された追加のパラメーターは、パスレベルのパラメーターと組み合わせて使用されます。
1paths:2 /users/{id}:3 parameters:4 - in: path5 name: id6 type: integer7 required: true8 description: The user ID.9
10 # GET/users/{id}?metadata=true11 get:12 summary: Gets a user by ID.13 # Note we only define the query parameter, because the {id} is defined at the path level.14 parameters:15 - in: query16 name: metadata17 type: boolean18 required: false19 description: If true, the endpoint returns only the user metadata.20 responses:21 200:22 description: OK
特定のパスレベルパラメータは操作レベルで上書きできますが、削除することはできません。
1paths:2 /users/{id}:3 parameters:4 - in: path5 name: id6 type: integer7 required: true8 description: The user ID.9
10 # DELETE /users/{id} - uses a single ID.11 # Reuses the {id} parameter definition from the path level.12 delete:13 summary: Deletes the user with the specified ID.14 responses:15 204:16 description: User was deleted.17
18 # GET /users/id1,id2,id3 - uses one or more user IDs.19 # Overrides the path-level {id} parameter.20 get:21 summary: Gets one or more users by ID.22 parameters:23 - in: path24 name: id25 required: true26 description: A comma-separated list of user IDs.27 type: array28 items:29 type: integer30 collectionFormat: csv31 minItems: 132 responses:33 200:34 description: OK
異なるパスにおける共通パラメーター
異なるAPIパスには、ページネーションパラメータなどの共通パラメータがある場合があります。共通パラメータはグローバルな parameters
セクションで定義し、$ref
を介して個々の操作で参照できます。
1parameters:2 offsetParam: # <-- Arbitrary name for the definition that will be used to refer to it.3 # Not necessarily the same as the parameter name.4 in: query5 name: offset6 required: false7 type: integer8 minimum: 09 description: The number of items to skip before starting to collect the result set.10 limitParam:11 in: query12 name: limit13 required: false14 type: integer15 minimum: 116 maximum: 5017 default: 2018 description: The numbers of items to return.19paths:20 /users:21 get:22 summary: Gets a list of users.23 parameters:24 - $ref: "#/parameters/offsetParam"25 - $ref: "#/parameters/limitParam"26 responses:27 200:28 description: OK29 /teams:30 get:31 summary: Gets a list of teams.32 parameters:33 - $ref: "#/parameters/offsetParam"34 - $ref: "#/parameters/limitParam"35 responses:36 200:37 description: OK
グローバルな parameters
はすべての操作に適用されるパラメーターではなく、単に再利用しやすいグローバルな定義であることに注意してください。
パラメーターの依存関係
Swagger はパラメータの依存関係や相互排他的なパラメータをサポートしていません。https://github.com/OAI/OpenAPI-Specification/issues/256 で未解決の機能リクエストがあります。できることとしては、パラメータの説明に制約を文書化し、400 Bad Request レスポンスでロジックを定義することです。例えば、相対的な日付範囲 (rdate
) または正確な範囲 (start_date
+ end_date
) のいずれかを受け入れる /report
エンドポイントを考えてみましょう。
1GET /report?rdate=Today2GET /report?start_date=2016-11-15&end_date=2016-11-20
このエンドポイントは次のように記述できます。
1paths:2 /report:3 get:4 parameters:5 - name: rdate6 in: query7 type: string8 description: >9 A relative date range for the report, such as `Today` or `LastWeek`.10 For an exact range, use `start_date` and `end_date` instead.11 - name: start_date12 in: query13 type: string14 format: date15 description: >16 The start date for the report. Must be used together with `end_date`.17 This parameter is incompatible with `rdate`.18 - name: end_date19 in: query20 type: string21 format: date22 description: >23 The end date for the report. Must be used together with `start_date`.24 This parameter is incompatible with `rdate`.25 responses:26 400:27 description: Either `rdate` or `start_date`+`end_date` are required.
FAQ
「type」と「schema」はいつ使い分けるべきですか?
schema
は in: body
パラメーターでのみ使用されます。その他のパラメーターは、type: string
のようなプリミティブ型、またはプリミティブの array
を期待します。
オブジェクトをクエリパラメーターとして使用できますか?
OpenAPI 3.0 では可能ですが、2.0 ではできません。
お探しのものが見つかりませんでしたか? コミュニティに質問する
間違いを見つけましたか? お知らせください