やってみる

アウトプットすべく己を導くためのブログ。その試行錯誤すらたれ流す。

APIクライアント自動作成について考えてみた

こんなことができたらいいな、という妄想。

問題

WebAPIクライアントをいちいち作るのが大変。

  • いちいち異なるサービスごとにクライアントライブラリを使い分けるのが大変
  • いちいちAPIごとにソースコードを書くのが大変
  • 仕様変更ごとに修正するのが大変

まるでO/Rマッピングを手でやっているような無駄感、虚無感。自動化ツールはないのか。

理想

WebAPIを実行するPythonコードを自動作成したい。

  • ソースコードを変更することなく、DB操作だけでAPI追加したい
  • DB操作はAPI仕様データから自動抽出する
    • API仕様に更新があればサーバプッシュで受け取る
    • 仕様データの取得はHTMLによるWebスクレイピングでなく、何らかのマシンリーダブルなデータ形式で取得できる

できれば他のプログラミング言語も。さらにCUI,GUIのインタフェース層作成まで自動化できたら最高。

結論

SOAP+WADLなら一部可能?未確認。

RESTfulはむずかしい。誰かが作ったAPIクライアントを使うのが現実的か。

理由

REST規格が曖昧だから定形処理化できない。

  • REST(RESTful)
  • SOAP

WebAPIは上記2つの規格がある。SOAPはWADLによりクライアントの自動作成ができるらしい。対してRESTfulはできない。規格が曖昧で自由度が高すぎるから。

http://qiita.com/pink/items/f1a22840619d3b79c4f2
https://teratail.com/questions/34703

RESTなWebAPIを自力で自動化はむずかしい

  • API仕様の自由度が高い
    • RESTful
    • HTTP規格
    • TSL規格
    • 自由度が高すぎ。ベンダが自由に決められることが多すぎ。定型処理化すべき範囲が広すぎる
  • API仕様の取得を自動化できない
    • API仕様書からWebスクレイピングで取得せねばならない(結局は人力作業)
    • 自然言語から意味を解析してプログラミングコードに落としこむ必要がある
  • プログラミング言語ごとのクライアント
    • 言語仕様が違う

引数と戻り値

とくにパラメータなどは制約をコードに落としこむのが難しい。また、応答形式にも幅がある。ストリームか否か、バイナリ/テキスト。バイナリなら画像、音声、映像。各デコーダ/エンコーダ。テキストなら文字セット(UTF-8,Shift-JIS,…)や形式(plain,html,xml,json,…)などがある。何も意識せずにすむ共通化コードを書くにはあまりに規模が大きくなってしまう。

通信規格

通信規格は変わる可能性もある。ネットワーク通信規格は進化していく。また、利用体系で使い分けるかもしれない。

そんな最中、それらを共通化することは規模が大きすぎて難しい。

調査

すでに規格があったり、誰かが作ったりしてくれていないか。

WebAPI クライアント 自動作成ググる。いくつかのキーワードを発見するも、よくわからない。

WADL: WADL(Web Application Description Language)を利用した Web API の作成 - よしなしごと
Grape: http://qiita.com/HKDnet/items/0267606d5f47fe4ffdf4
LoopBack: http://qiita.com/kyrieleison/items/defee6a9450b18ae9554
Parasoft SOAtest: http://parasoft-techmatrix.blogspot.jp/2012/12/rest-api.html
CData API Server: データベースからWeb APIを手軽に自動生成する「CData API Server」ベータ | マイナビニュース

理由の邪推

わざとWebAPIを使いづらいままにしているのかもしれない。

  • 簡単に使われてしまうと利用者と頻度が増えてサーバ負荷が増える
    • 提供側の負担とリスクが増える
  • API利用が増えてサイト閲覧が減ると広告を見てもらえなくなり収益低下する

有料サービスならSOAPを使って自動化できるのかもしれない。使ったことがないので知らない。

所感

Web関連は余計な仕事が増える。セキュリティ然り、通信然り。APIの実装も自動化はむずかしい。ローカルが楽という結論になる。