のでメモしておく。
OpenAPI仕様 は乱暴に言うと『RESTなAPIはこのように定義しましょう』という仕様で、その手の仕様、規格の中では一番よく見かける気がするものだ。
WSDLを知っている人なら、そのRESTなAPI版だと考えるとしっくりくると思う。
現在はバージョン3で、2まではSwagger仕様と呼ばれていたので、インターネット上にはまだSwaggerとしての情報の方が多い状態だ。
元々この仕様は良いものだと思っていたのだが、 先ほどOpenAPI仕様を元にAzureのLogic AppsのCustom Connectorを作成してみた際に凄味を感じたので記事にしてその気持ちを忘れないようにした次第である。
何が良いと思ったのか？
定義にもとづく自動生成
OpenAPI仕様にもとづいた定義（JSONやYAML）があれば、そのAPI向けのクライアントコードやサーバコード（のインタフェース部分）を自動生成することができる。
APIの利用側にとってはクライアントコードの生成は非常に便利で、何度もその恩恵を受けたことがある。
OpenなAPIでなく、自サービスのAPIであっても、クライアントコードを手間なく、正確に生成できるのは大きな利点だ。
特に静的型付け言語で実装したAPIの場合は、追加のコードを書いたり修飾することなくリフレクションで定義を生成し、 その定義からクライアントコードを生成する事が出来る。
これは実装労力とインタフェース齟齬のリスクを大幅に低減してくれてとても素晴らしいAPIの開発形態になると思っている。 （何度か実感もしている）
定義にもとづくサービス利用
先の自動生成はもともとよいと思っていたことだが、こちらは今回実感したよさである。
近年ではフローベースのアプリケーションが元気だと感じていて、Microsoftにもその名の通りFlowやLogic Appsなどその類のサービスがある。
これらのサービスで共通して使用できるフロー要素を独自に作成することができ、それがカスタムコネクタだ。
このカスタムコネクタは、OpenAPI仕様の定義を元に作成できるのだが、これが本当に定義を指定するだけで作成できてしまうのだ。
なかなか感動する。
作成したコネクタはすぐにLogic Appsなどに配置して使用することができる。
この手軽さ、実用性はすさまじい。
感動はこちら。
Azure Logic Appsいい。
— 光電/7474 (@koudenpa) July 22, 2018
カスタムコネクタ作成から使うまで30分かからなかった。
（まぁ、ドキュメントはちょいちょい読んでいた&同系のフローエンジンは触ったことあるが）
コネクタのパラメータの型に応じて使える入力の候補が切り替わるのがいい。そもそも候補が出てくるのに驚いた。スゴイ。 pic.twitter.com/rDpkQLCzuo
オチはない
純粋にエコシステムとしてすごいと思ったのであった。
