生成するというアプローチを取りました。https://swagger.io/specification/なのでざっくりとした手順は以下の通りです。そのものがどんなAPIなのか?についてざっくりとおさえておきます。他、ログイユーザーのID・PWが必要です。」に含めてリクエストすればOKです。リフレッシュする場合は「grant_type=refresh_token」で。アプリで使われているものを利用します。認証部分定義は使わず、Tokenエンドポイントだけ通常のPathとして実装しました。系エンドポイントデータ取得系エンドポイントはシンプルです。エンドポイントを実行し、車両IDを特定します。取得できるようになります。以下のようなリクエストですね。/api/1/vehicles/{id}/vehicle_dataちなみに、Dataがすべての情報を返すエンドポイントで、もう少し細かいグループで取得できるのが、Data以外の各種エンドポイントです。単純にすべてのデータを見たいなら、Dataエンドポイントを叩くだけでOKです。車両IDを特定してからリクエストを行います。以下のような感じです。/api/1/vehicles/{id}/command/flash_lightsなお、コマンド系のレスポンスは車両を起動するためのWakeを除いて、すべて以下のようなレスポンスを返します。これはすべてURLパラメータとして指定します。POSTだからといって、FromやJSONで渡すわけではないので、要注意です。作り方(メイン)とりあえず以上の要素さえおさえておけば、特に難しいAPIというわけではありません。このReferenceを元にしながら、OpenAPIを愚直に書き起こすだけです。実際に仕上がったものが以下のYAMLです。生のYAMLで書くのは正直かなりツライです。Specを書き起こすために、色々とツールを駆使したので紹介していきます。Studio」がオススメです。https://stoplight.io/動かしているイメージはこちらから。Serverを立てくれるところ、どれをとっても素晴らしい・・・。Studio」を採用するポイントは以下の3つです。ServiceですぐにAPIを試せる「1.」は上記画面でも分かる通り、リソースとそれらに対応するメソッドの一覧性が良く、必要なエンドポイントとメソッドが網羅されているかどうか確認がしやすいです。「2.」はレスポンスの定義としてかなりの数のモデルを使い回すことが初めからわかっていたので、かなり重要でした。Studio」はSpecの中のモデルだけではなく、プロジェクトベースでモデルを使い回すことができ、一つのSpecを肥大化を防ぎます。Serviceが自動で生成されるというものです。リンクをクリックすれば、そのままGETリクエストがブラウザで実行されて、即エンドポイントの仕様を確認できます。Postmanから実行してもOKです。認証のレスポンスだけでも、気が遠くなります。モデルを自動生成してくれるツールで一気に自動生成してしまいました。https://swagger-toolbox.firebaseapp.com/https://kageura.hatenadiary.jp/entry/swaggertoolboxなので、以下のようなJSONデータも上記のYAMLにサクッと変換。プロジェクトに取り込んで、すべて定義してしまいました。これで、あとはひたすらPathを追加して、Modelを紐付けていくという単純作業になりました。下調べの時間を省くと、実質1時間ほどで完成したかなと思います。Serverを生成してデプロイするだけです。Generatorを素直に使いました。https://openapi-generator.tech/手順は簡単。Node.jsを入れておきましょう。-gあとは、以下のようなコマンドで生成できます。https://openapi-generator.tech/docs/generators/aspnetcoreこんな感じで生成されます。素晴らしいのは、Model定義でちゃんとExampleを入力しておけば、それに従って、ダミデータを返してくれるエンドポイントを実装してくれるところです。23時、以下の記事を追加しました。(翻訳)Twitter@sugimomotoさんのツイートはてなブログをはじめよう!sugimomotoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。