* 前提条件 [#q5fb98a5]
OpenAPIの定義がある状況で、管理画面を早く正確に作ることがゴールである場合の手法について考察してみる。




管理画面は、ユーザが使うものではないから、デザインはそこそこのレベルがあればいい。

画面までの自動生成であれば、データベースのテーブル作成も範囲に含めてならば、jhipsterがいい感じにCRUDを行える画面作成までやってくれる。

しかし、DBは既存であり、しかもそこには、API経由でしかアクセスできない場合、どのような手法が考えられるだろうか?

まずは半自動でもいいので考える。作業量が減って正確であればいいのだから。

** 一覧表示系の画面を効率よく作成するパターンについて考える [#haf69728]

アイデアとしては、APIでGET系のレスポンスの構造を解析し、それをJDLで記述するというやり方だ。

JHipsterで生成されたコードの修正箇所は、まずDB関係のコードは不要になるだろうし、
そのDBにアクセスしに行っている箇所を差し替えなくてはならない。

差し替える用のコードは、openapi-generatorでクライアント用のコードを生成したものと差し替える必要がまずはあるだろう。

ここまでが自動生成のほうが早くて、自動化できそうな箇所であろう。

そこまで行ったならば、こんどは、openapi-generatorで生成したコードが外部のAPIから読み込んだデータを、jhipsterで生成したDAOとして取得するように修正する必要がある。

この手法は、おそらく毎回似たような対応で済むだろうから、知見が増えやすいと思う。

** 新規作成・更新系の画面は、どうだろうか?これは、openapiの定義のメソッドの種類で、POST、PUTのリクエストパラメータを分析して、JDLを作成するというのでどうだろうか? [#bb5885ab]

jhipsterで生成したコードのうち、saveメソッドでDBを更新しに行っている箇所を以下のもので差し替える作業となるであろう。
差し替えるものは、openapi-generatorで生成したクライアント用コードである。

ここまでが自動生成したコードであり、あとの作業としては、
openapi-generatorで生成したコードが外部のAPIに更新しに行く修正である。

** openapiからjdlを生成するツールの要件を考える [#qb2c1e1c]
open-apiを解析しjdlを生成するというのを手作業でやると、apiの数が膨大な場合

詰んでしまう。なので何らかのツールがあったらよいということになる。

まず、apiがgetメソッドの場合は、レスポンスを解析してJDLを生成する機能が欲しい。

次にapiがpost、putメソッドの場合は、クエリパラメータを解析してJDLを生成する機能が欲しい。


*** openapi-generatorの調査対象 [#wa603dc9]
openapiのyamlをパースした後、パラメータについてのコードを生成している箇所とレスポンスを生成している箇所について調査が必要と考える。

トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS