クライアント側とサーバー側が非同期で開発を進めることができる
土田氏はOpenAPIを利用したこのような開発スタイルの最大の利点として、「クライアント側とサーバー側が非同期で開発を進めることができる」点を挙げる。API仕様の確認のために打ち合わせを繰り返す必要がなくなるため、それぞれのペースで開発を進めることができるのだ。実際に土田氏は、さらなる利点として「サーバー側とクライアント側の開発者間のコミュニケーションコスト削減」を挙げている。
そして土田氏は3つ目の利点として、自動生成を挙げた。OpenAPI形式でAPIの定義文書ができれば、必要なライブラリなどを自動的に生成できるのだ。コードを人間が実装する工数を削減できるだけでなく、決まった形式の定義文書からコードを自動的に生成するため、間違いも減らせる。
OpenAPI形式の定義文書から自動的に生成できるものとしては、まずクライアント用のライブラリが挙げられる。これによってHTTPの通信を開発者が自身で実装する必要がなくなり、より抽象度の高いライブラリのAPIを呼び出して機能を実装できる。
次に、サーバー側APIのモックが挙げられる。クライアント側がサーバー側との通信を試すとき、実際にサーバー側のAPIと通信してみるのが最も確実な手段だが、サーバー側APIの実装が完了するのを待たなければならない。これではクライアント側とサーバー側が非同期で開発を進めるという利点がなくなってしまう。そこで、APIの名称と呼び出し方と戻り値を再現するモックを利用するのだ。
さらに最近では、OpenAPI形式の定義文書からサーバー側のコードを自動生成することができるようになってきている。これでサーバー側もAPIの定義と実装がずれることがなくなり、工数を削減できるのだ。
ただ、土田氏によるとOpenAPIファイルを利用するだけでは、解決しない問題があり、新たな問題を起こすこともある。よくある問題として土田氏は3点挙げた。1つ目はYAMLやJSONのファイルが開発者にとって読みやすいものではないということ。メンバー全員でOpenAPIファイルをレビューするときに、手間と時間がかかる。
2つ目はAPIの定義がデータベース設計に強く依存すること。途中でデータベース設計を変更すると、APIの定義も修正が必要になるが、修正が漏れてしまうことが長期的なプロジェクトではよくあると土田氏は指摘する。3つ目は、データベースを操作するCRUD（Create：データの作成、Read：読み出し、Update：更新、Delete：削除）のAPIの定義を書くのに大きな労力がかかるということだ。
