OpenAPIの理解を深めるために作成した前回の記事で予告した基本構造作りをします。
最初から色んな事をやり過ぎると混乱に落ちる可能性があるので、パラメータに設定したテキストを編集して返すAPIを呼び出す処理を実装する事にしました!
APIの実装やOpenAPIドキュメント作成のみではなく、OpenAPIの変換や動作確認も必要なので、ゆっくり進みましょう。
今回の流れは?
- バックの処理を実装、シンプルにGCPのCloud Functionsで実装
- OpenAPI V3ドキュメント作成
- OpenAPI V3ドキュメントをOpenAPI V2ドキュメントに変換
- 変換したV2ドキュメントを確認&修正(修正は必要な場合)
- V2ドキュメントを持ってApigeeでSpec及びProxiesの生成
- 最後の動作確認
今回はステップが多く、あれこれやって行きます。
目次
0.事前準備、必要なものは?
順番に実施しながら用意すればいいので、事前に準備するものはありません。
記事を読みながら一つずつ整えて行きましょう!
1.まずはバックエンド処理を用意する
OpenAPIドキュメント作成より先に叩く対象を準備します。APIを作りましょう。
Cloud Functionsでnode8ベースのJSを実装します。
(もしくは同じ処理ができるものを構築してもOKです。)
1.1.GCPから関数を作成するには?
GCPコンソールのメニューからCloud Functionsを選択します。
‘関数を作成’ボタン押下
表示される項目の中から名前のみ変えました。
他の項目は修正する必要がないので、初期値のままでOKです。
index.jsに書いてあるスクリプトを下記の内容に修正します。
// Queryパラメータに設定されているinputTextの有無で、編集内容が変わる
let message = 'Hello, ' + (req.query.inputText || 'World') + '?';
// CORS対応
res.header('Access-Control-Allow-Origin', "*");
res.header('Access-Control-Allow-Headers', "Origin, X-Requested-With, Content-Type, Accept");
修正後のコード
修正が終わったので画面の下にある’作成’ボタンを押下し関数を作成します。
少し待つと作成が終わります。
問題なく作成されたので関数をクリックし、動作確認をしましょう
1.2.関数、始動!
関数名をクリックすると関数の詳細情報が表示されます。
そこからトリガータブをクリックし、画面に表示されたURLをクリックします。
「Hello, World?」が表示されましたか?そうであればバックエンドは準備完了です。
パラメータが存在する場合、パラメータと結合されたテキストが返されるので、今はWorldが結合された形態のテキストがリターンされます。
パラメータ設定時
では次の段階へ〜
2.ここが作業の本番、OpenAPIドキュメント作成
上の工程で作成したバックエンドを呼び出すOpenAPIドキュメントを作成する番です!
ドキュメントに入る要素話は前回の記事を参考に、どんな要素が定義されるのか理解しながら進みましょう。
※OpenAPI V3を作成するのでV2を支援するApigeeでは変換せずに使用する事は不可能です
2.1.最強の道具!?その名はSwagger Editor
Swagger Editorはウェブブラウザ上でOpenAPIドキュメント作成が可能で、作業し易い環境を提供します。
別途のプログラムインストールや会員加入などが不要なので、楽に作業開始ができます。
まずはhttps://editor.swagger.io/に入りましょう、サンプルのドキュメントが表示されます。
サンプルとは言え動作するものなので、少し叩いて見るのも良いです。
ここで、僕らが作業する場所は左側にあるエディターです。
作成準備ができたので、エディターの内容を下記のものに入れ替えてください。
YAML形式で作成したシンプルで分かり易い要素のみで詰め込んだ、OpenAPIドキュメントとなります。
あ、Serverオブジェクトの中身を自分の環境に合わせて修正する事を忘れないでください〜!
下記の内容は僕の環境に合わせた作例として載せましたので、サーバの向き先修正を必ず!実施すること!!
※1.OpenAPIドキュメント作成時、各要素を一つずつ追加する事でどう変化するかを確認することをお勧め!目で見ることで理解が深まります。
※2.各要素の説明は行いませんので、前回の記事を参考にしてください。
openapi: 3.0.2
info:
title: Hello World
description: what's your name? speak to!
termsOfService: https://policies.google.com/terms?hl=ja&gl=JP
contact:
name: Cloud Ace Technical Blog
url: https://www.apps-gcp.com/
email: test@apps-gcp.com
license:
name: license by Open Source Initiative
url: https://opensource.jp/osd/osd-japanese.html
version: '1.0'
servers:
- url: 'https://us-central1-{projectName}.cloudfunctions.net' ← 自分が構築した環境のものに修正、下のServer変数は使い方の例として入れたものなので消してもOK
description: Step1, call API
variables:
projectName:
enum:
- ca-iwans-test
- google-test
default: ca-iwans-test
description: set project
paths:
/Hello-OpenAPI:
summary: Hello, XXXX?
description: this api, combine to Hello world and parameter text
get:
summary: return combine text
description: Hello, + parameter.text + ?
externalDocs:
url: https://www.apps-gcp.com/openapi_understanding_dissection/
description: previous post
operationId: combineText
parameters:
- name: inputText
in: query
description: user input
required: false
deprecated: true
allowEmptyValue: true
schema:
type: string
responses:
default:
description: return to api response
content:
text/plain:
schema:
type: string
deprecated: false
上記の内容に入れ替えるとエディターの右側にサーバの選択(サーバ変数の値変更も)や実行するAPIに関する情報などが表示されますので、問題なく動くのか試して見ましょう。
[ GET ] /Hello-OpenAPI をクリック → Try it Outボタン押下 → パラメータinputTextに任意の値を入力 → Executeボタン押下の順になります。

パラメータの値が含まれたテキストがレスポンス欄に表示されたならOKです。
※この記事が上がっている時点だと作例に載せたサーバのアドレスは廃止状態ですので、表示されないor接続エラー的なものが発生したらServerオブジェクトをもう一度チェックすること!バックエンドが用意されてないのであれば用意しましょう。
本当は作例からサーバ情報のみを修正してそれをYAMLに保存するだけで良いのですが、OpenAPIドキュメントを作成しながら動作確認をする方法を覚えておく必要があったので、Swagger Editorを使用しました。
2.2.作成したものを保存して見よう
エディターのメニューから保存できます。
公式ドキュメントから推奨されるファイル名で保存される又は保存しようとするので、なぜ推奨されるのか詳しい内容は記載されてないのですが、それらしい理由があると信じて!ファイルを保存しましょう。
動作確認も終えた事だし、保存もできたし、Apigeeで活用できる形にしないと行けませんね、変換しましょう!
3.V3 → V2、ドキュメントバージョン落とし!
最新バージョンに適応する為にOpenAPIドキュメントは最新のV3で作成していますが、これだとApigeeでは使い物になりません。
3.1.変換どうしよう?
APIMATICを利用すればV3をV2に変換できます。
加入しないといけないので、少し工程が長くなりますが、このサイトを知っておくと何かしら役に立ちそうなので、体験する事にしました。
※このサービスは有料ですがタイムトライアルでお試しできる期間があります
トライアル後の使用には注意しましょう(プラン加入が必要)
ステップ1. Sign up! 加入する
ステップ2. Log in! 接続せよ
ステップ3. ログイン後に表示される画面からトランスフォームAPIをクリック
ステップ4. Choose file押下後、変換対象のYAMLファイルを選択
ステップ5. ファイルが設定されている事を確認、Export FormatからOpenAPI/Swagger V2.0 (YAML)を選択後、Convertボタン押下
ステップ6. 変換対象のファイルチェック後、お知らせが表示されます
エラーや注意事項などがあればそれの対応が必要になるので無視せず、内容確認後Proceedを押してください
今回の場合、テストケースが生成されたことと一部の要素に説明フィールドが存在しないと言うメッセージだけなので次へ進みましょう(APIMATICに何かを構築しているわけではないので、テストケースの話がなんで出たのか分かりません)
変換に成功しました!
変換後のファイル名にはSwaggerYamlが含まれているので、怪しいものだと疑わないように!!
これでファイルの変換は完了しましたが、OpenAPIドキュメントの仕様上、要素の有無や要素名が違うものとかもありえるので、変換したものの内容チェックが必要です。
4.変換したV2ドキュメントの確認
変換は成功で、動作確認もちゃんと取れると思いますが、変換結果物をよく見ると何かが足りないところが出てくると思います。
変換するんだとしても漏れ無くV3の要素をV2に引っ張ってくるものではないようで。。
では、これからOpenAPI V2の要素を探りながら進めましょう。
4.1.メタデータの違い
V3のメタデータはopenapiとinfoオブジェクトで構成されています。
V2の場合、infoオブジェクトはV3と同じなので、openapiの代わりの要素に注意する必要があります。
V2のメタデータは下記の通り
フィールド名 | データタイプ | 必須 | フィールド説明 |
swagger | string | YES | V3のopenapiがV2ではこれに該当する Swaggerのバージョンを記載するが、V2は 他のバージョンが存在しないため、 必ず ’2.0’ を記載する |
info | Info オブジェクト |
YES | V3の構成と同一 |
変換されたソースを見ましょう
swagger: '2.0'
info:
version: '1.0'
title: Hello World
description: what's your name? speak to!
contact:
email: test@apps-gcp.com
name: Cloud Ace Technical Blog
url: https://www.apps-gcp.com/
# 追加部分_Start
termsOfService: https://policies.google.com/terms?hl=ja&gl=JP
license:
name: license by Open Source Initiative
url: https://opensource.jp/osd/osd-japanese.html
# 追加部分_End
termsOfServiceとlicenseオブジェクトが欠落されていたので、追加しました。
それ以外はちゃんと変換されましたね。
4.2.構成が全然違うサーバ情報
V3は一つのオブジェクトの中に定義されるものが、V2だとバラバラに。。なのでちょいと厄介なものになりました。
V2のサーバ情報は下記の通り
フィールド名 | データタイプ | 必須 | フィールド説明 |
host | string | ホスト名、IPを記載する(必要ならポート番号も) ただし記載するのはホストアドレスのみで、下位経路は記載しない パスパラメータ未支援 |
|
basePath | string | APIが提供されるパス ホストを基準に‘/’から始まる相対パスを記載する ホスト直下でAPIが提供される場合、‘/’のみ記載 パスパラメータ未支援 |
|
schemes | string リスト |
API伝送プロトコル、値は必ず”http”, “https”, “ws”, “wss”の中から選ぶ 設定されてない場合、このAPIに接近する方式と同じものが使用される |
|
consumes | string リスト |
APIが使用可能なMIMEタイプ 使用範囲はOpenAPI全体だが、特定のAPIでオーバーライドすることができる Mime Typesに定義されている値を使用するべき |
|
produces | string リスト |
APIが生成可能なMIMEタイプ 使用範囲はOpenAPI全体だが、特定のAPIでオーバーライドすることができる Mime Typesに定義されている値を使用するべき |
変換されたソースを見ましょう
host: us-central1-ca-iwans-test.cloudfunctions.net
basePath: /
schemes:
- https
consumes:
- application/json
produces:
- application/json
V2でのサーバ情報は上のソースをベースに説明すると、
hostにホストアドレスを記載→basePathにホストアドレスからエンドポイントまでの経路を記載→schemesにプロトコルを記載する流れで完成されます。
consumes、producesは伝送&受信されるデータタイプを指定します。
V3との一番大きい差は!サーバ変数が使用不可と言うことです!!
なので、アドレス指定は常に一つしかできません。
4.3.パスとメソッド
V3と比べて見ると一部の要素が存在しません
概要、説明、サーバ情報、そしてHTTPメソッドの内 ‘trace’ を使えないので注意
V2のパスオブジェクトは下記の通り
フィールド名 | データタイプ | 必須 | フィールド説明 |
paths | Paths オブジェクト |
YES | API操作とパスを定義する 複数実装可能 |
paths/{path} 又は paths/‘x-’ で始まる 拡張機能を 使用 |
Path Item オブジェクト ※{path}は string |
スラッシュから始まるエンドポイント、 ベースとなるURLの後ろに結合される パスパラメータ支援 ※V3との違いはカスタムプロパティーを支援 することで、OpenAPIでは支援しない機能 を使用することができます。 詳細はSwagger Extensionsを参照 他のオブジェクトも支援するので それも要チェック! |
|
paths/{path}/ $ref |
Reference オブジェクト |
使い方はV3と同一 ただ定義先が違うだけで、V3だとComponents オブジェクト、V2だとDefinitionsオブジェクト となる |
|
paths/{path}/ {http method} |
Operation オブジェクト |
HTTPメソッドの定義、支援するタイプは get, put, post, delete, options, head, patch 複数のメソッド定義可能 オブジェクトの詳細は別途の表で説明 |
|
paths/{path}/ parameters |
Parameters オブジェクト 又は Reference オブジェクト のリスト |
パス内部で使用可能なパラメーターのリスト オブジェクトの詳細は別途の表で説明 |
前回の記事と同じくパラメータから確認します。
4.3.1.Parametersオブジェクト
V3と同じ要素は一部のみ、他の構成が違うので確認しておく必要があります。
フィールド名 | データタイプ | 必須 | フィールド説明 |
parameters/ name |
string | YES | パラメータ名、英字の大小文字を区別する 下にある’in’に設定されているパラメータ格納先に設定されたパラメータ名と同一でなければならない |
parameters/ in |
string | YES | パラメータが設定される場所を指定する “query”, “header”, “path” とV3には存在しない”formData”と”body”が存在する ”formData”の場合、application/x-www-form-urlencoded、multipart/form-data二種類のコンテンツタイプが使用可能 |
parameters/ description |
string | パラメータの説明 ※説明要素は全てGFM syntaxを支援する V3はCommonMarkを支援する |
|
parameters/ required |
boolean | パラメータに必須設定をする inがpathの場合、この要素は必ずtrueを設定する そうでないと初期値がfalseになる |
inがbodyの場合
フィールド名 | データタイプ | 必須 | フィールド説明 |
parameters/ schema |
Schema オブジェクト |
YES | パラメータで使用される型を定義する。 プリミティブ型、配列なども定義可能 詳細と使用例を参照 |
inがbodyではない場合
フィールド名 | データタイプ | 必須 | フィールド説明 |
parameters/ type |
string | YES | パラメータのタイプを指定する リクエストボディー内部に一している 訳ではないので、オブジェクト以外の 方に制限されます。 指定可能なのは”string”,”number”, “integer”,”boolean”,”array”,”file”で、 “file”の場合はOperationオブジェクト のconsumesが”multipart/form-data” 又は”application/x-www-form-urlencoded” を記載するかこの二つ全部記載するか にしてinを”formData”にする必要がある |
parameters/ format |
string | パラメータのデータ型を指定する 指定可能なフォーマットはここを参照 |
|
parameters/ allowEmptyValue |
boolean | 空の値設定を許可する “query”, “formData”の時に有効であり、 初期値はfalse |
|
parameters/ items |
Items オブジェクト |
typeが”array”の場合必須、 配列内部のアイテムを定義する ※オブジェクト構成は”inがbodyでは ない場合”の構成と同じで一部のみが 違う(内部にItemsオブジェクトも存在する) 1.typeに”file”指定不可 2.allowEmptyValue要素が存在しない 3.collectionFormatに”multi”指定不可 |
|
parameters/ collectionFormat |
string | パラメータが配列の場合使用される 使用かのなのは下記の通り csv – コンマ区切り ssv – 空白区切り tsv – タブ区切り pipes – パイプ区切り multi – 単一パラメータではなく 複数パラメータの場合に使用する (例:foo=bar&foo=baz) これはinが”query”又は”formData” の場合に有効、初期値はcsv |
|
parameters/ default |
自由記載 | パラメータが未設定の場合、初期値 として使われるパラメータのデータ型に 準拠する事が必須 |
|
parameters/ maximum |
number | パラメータの最大値を設定 | |
parameters/ exclusiveMaximum |
boolean | trueの場合、最大値より小さい値が有効 falseの場合、最大値より小さいか等しい 値が有効 未定義の場合、初期値はfalse |
|
parameters/ minimum |
number | パラメータの最小値を設定 | |
parameters/ exclusiveMinimum |
boolean | trueの場合、最小値より大きい値が有効 falseの場合、最小値より大きいか等しい 値が有効 未定義の場合、初期値はfalse |
|
parameters/ maxLength |
integer | パラメータの文字数がこの値より少ないか 等しい場合、有効 |
|
parameters/ minLength |
integer | パラメータの文字数がこの値より多いか 等しい場合、有効 未定義の場合、初期値は0 |
|
parameters/ pattern |
string | パラメータチェック用正規表現 パラメータがパターンと一致する場合、有効 |
|
parameters/ maxItems |
integer | パラメータが配列の場合、配列の数が この値より少ないか、等しい場合に有効 |
|
parameters/ minItems |
integer | パラメータが配列の場合、配列の数が この値より多いか、等しい場合に有効 未定義の場合、初期値は0 |
|
parameters/ uniqueItems |
boolean | パラメータが配列の場合、各要素の一意性 を検証 trueの場合、全ての要素が一意であれば有効 falseの場合、検証しない 未定義の場合、初期値はfalse |
|
parameters/ enum |
自由記載 リスト |
定義する場合、必ず一つ以上の要素が 存在する必要がある配列 各要素に入る値はnullを含む任意の型で ありながら一意のものでないといけない パラメータの値がこの配列に入っている 要素中、一つでも合えば有効 |
|
parameters/ multipleOf |
number | 値は0以上のnumberを入れること この値でパラメータを割り算した結果 integerになるなら有効 |
4.3.2.Operationオブジェクト
このオブジェクトの構成はV3がV2をベースに追加要素を入れたものなので、
ここではV3にあってV2にない要素、V3と内容が違う要素を説明します。
※postメソッドだと仮定してフィールド名を記載します
フィールド名 | データタイプ | 必須 | フィールド説明 |
post/ summary |
string | V3との違いは文字数制限が存在すること 120字未満であるべき |
|
post/ schemes |
string リスト |
要素の説明は4.2のサーバ情報を参照 V2のみ存在する |
|
post/ consumes |
string リスト |
要素の説明は4.2のサーバ情報を参照 V2のみ存在する |
|
post/ produces |
string リスト |
要素の説明は4.2のサーバ情報を参照 V2のみ存在する |
|
post/ requestBody |
V2には存在しないが、 Parametersオブジェクトでinがbodyの場合、 これの代わりになる |
||
post/ responses |
Responses オブジェクト |
YES | 別途の表でV3との違いを解説 |
post/ callbacks |
V2には存在しない | ||
post/ servers |
V2には存在しない |
Responsesオブジェクト
ここはV3と比べ構成要素が半分違うので、一つ一つチェックしながら行きます。
※ステータスコードは’200’を仮定してフィールド名を記載します
フィールド名 | データタイプ | 必須 | フィールド説明 |
default 又は HTTP ステータスコード |
Response オブジェクト 又は リファレンス オブジェクト |
V3と大きい違いはワイルドカードが使用 不可だと言う事、ここに定義されている ステータスコードを指定してあげる必要あり |
|
‘200’/ description |
string | YES | V3と同一 |
‘200’/ schema |
Schema オブジェクト |
V2のみ存在、レスポンスのコンテンツ を定義するコンテンツはプリミティブ型、 配列又はオブジェクトにもなれる のでそれを定義してあげる 未定義の場合、送信されるコンテンツ が存在しないことを意味する producesに関連するMIMEタイプを指定 する必要がある オブジェクトの詳細と使用例を参照 |
|
‘200’/ headers |
Headers オブジェクト |
V2にも存在するオブジェクト | |
‘200’/ headers/ {name} |
Header オブジェクト |
V3とのヘッダー名指定が違う V3だとマップのキーに指定するが、V2は パス名指定と同じ方式で定義する オブジェクト内部の構成はV2のItems オブジェクトと同一だが、ここは追加で description要素が存在する |
|
‘200’/ examples |
Example オブジェクト |
V2のみ存在する レスポンスに設定されるコンテンツの 例をproducesに指定したMIMEタイプに 合わせて記載する。詳細はここを参照 |
|
‘200’/ content |
V2には存在しない | ||
‘200’/ links |
V2には存在しない |
変換されたソースを見ましょう
paths:
/Hello-OpenAPI:
get:
description: Hello, + parameter.text + ?
summary: return combine text #値が違ったので、修正
operationId: combineText #自動生成された値だったので、修正、
deprecated: false
produces:
- text/plain
parameters:
- name: inputText
in: query
required: false
allowEmptyValue: true #削除されていたので、追加
type: string
description: user input
responses:
200:
description: return to api response
schema:
type: string
headers: {}
externalDocs:
url: https://www.apps-gcp.com/openapi_understanding_dissection/
description: previous post
# 削除対象_Start
definitions:
projectName:
title: projectName
example: ca-iwans-test
type: string
enum:
- ca-iwans-test
- google-test
tags: []
# 削除対象_End
返還後の品質チェック、下記の修正を行いました。
- オペレーションオブジェクトの中身を良く見るとsummaryとoperationIdが変わっていたので、V3の内容を元に修正
- パラメータの設定、deprecatedはV2に存在しない要素だから大丈夫なのですが、allowEmptyValueがなかったので追加
- どうやらサーバ情報に記載したサーバ変数がdefinitionsに入ってます。
だけどdefinitionsとtagsは不要なので、削除しましょう。
変換したV2ドキュメントのチェックが終わりました!長かったあ。。。
若干の修正が発生するもののこれぐらいの修正ならばV3でできている文書をV2に変換する作業に役立つものだと思います。
変換&修正後に異常がないことをSwagger Editorで動作確認をした後はApigeeに突入!!
5.ApigeeでSpec及びProxiesの生成
なんとかOpenAPI V3からV2への変換が成功したので、これを活用する番です。
5.1.OpenAPIドキュメント取り込み、Spec作成
Apigee Edgeにログインし、下記の順番で操作します。
① 左のメニューから’Spec’を選択
② ‘+Spec’ → ‘Import file’を選択
忘れずに変換前ではなく変換後のものを選択してください。
Import完了!リストに新しく追加したSpecが見えます。
ファイル名によってSpec名が決まるので、もし変えた場合、変えた名前が表示されます。
でも、これはファイル名と違いますね?なんだろう。。中身の確認をしましょう。
生成したSpecの中身を見る限り変換したもので間違いないようです。
お試しでImportしたSpecの動作確認を取りました。(実施方法はSwagger Editorと同一)
問題ないことを確認したのでプロキシ生成へ移ります。
5.2.Specからのプロキシ生成も簡単にできます
APIを構築するにはプロキシの生成が必要なので、ここ!を参考に実施してください。
Specの選択に間違いがないように注意!
※上記の流れを実施中にSpec選択後、’Internal Server Error’が発生した場合は下記の手順で乗り越えましょう。
(OpenAPIドキュメントからSpecを生成し、生成したSpecからプロキシを作ろうとすると’Internal Server Error’でプロキシが生成できないバグがあります。ここを参照)
既存のSpecは忘れ(バグの影響でプロキシ生成に使えない)再アップロードを実施します。
どうやらここからアップして実施するものには問題がないようです。。
① 上記のリンク先の流れだと’My Specs’タブから選ぶのですが、バグ回避のため’Upload file’から接近します
② ここをクリックし、OpenAPIドキュメントを選びましょう(Spec生成で使用したもの)
③ ファイルが設定されましたので、下の’Select’ボタンを押下
正常に処理された場合、下記のようなアドレスが表示されます
万が一!の場合もあるので、ファイル名を変えてSpec生成からやり直して見ました。
変換したドキュメントを下記の名前に修正。
Spec生成完了、今回は正しい名前で生成されました。
どうやら前回の生成ではファイル名に’.yaml’が入っていて途中で切れたようです。
新しく生成したSpecで、プロキシを作成して見ましょう!
あ、ダメだ。。。。
プロキシ生成段階でアップロードしてやるしかないようです。
こんなの初めてだ!!
Specの選択で問題が発生したものの回避策があって助かりました。。
続きの作業を実施し、プロキシの生成を完了しましょう。
ここまで来たのであれば?
最後の確認のみ
6.最後の動作確認
画面の操作やAPI実行手順などここだと省略されているものがあるので、ここを一回ご覧になってください。
まずは実施前のチェックポイント一つ!
プロキシリスト画面で、環境が’test’になっていることを確認してください。
プロキシ生成手順通りに進んだのであれば、稼働中のものはここにあります。
ステータス欄がキャプチャーの通り緑色であればOKです。
Apigee Edgeで今回生成したプロキシをトレースして、ちゃんとやり取りを行っているかを確認します。
https://apigee-restclient.appspot.com/ このRestクライアントを利用し、プロキシのアドレス+エンドポイント名(今回の作業で指定した’Hello-OpenAPI’)の組み合わせでURLを埋めてから’Send’ボタンを押下すると終わりです。
レスポンスの結果が表示されました!
クエリパラメータの設定をしてないため、Hello World?が表示されましたね。
続いてトレースの記録を確認しましょう。
結果を見る限り正しく正常終了した事が分かります。
クエリパラメータを追加してもう一回実行しました。
入力した値が結合された状態でレスポンスが戻ってきましたか?
トレースからも正常終了した事とレスポンス内容に間違いがない事が確認できました。
これで基本編終了となります!
まとめ
OpenAPIドキュメントを作成するために最初からV3ではなくV2で実装すれば楽になりそうですが、V2は古いのでV3を中心に勉強しておきたい気持ちでした。
その影響で少し厄介な中間過程が追加され、変換したり問題は無いか確認したりしましたけど、V3と同時にV2も把握して行く事になるので無駄にはならないと思います。
(内容は重くなりましたが;)
前回のV3解剖記事と同様にV2もドキュメントとの戦いだったので、頭痛い作業ではありましたが基本構造作りが出来て’どう作れば良い?’かの謎が解明された気がします。
この記事で扱った要素以外のものは次回の課題として残しておきます!
ではまた〜!
(あ。。。APIMATICどうしようか。。。)