APIStudy #5参加レポート - NTT Communications Engineers' Blog

APIStudy #5参加レポート

2月21日、高円寺のヴァル研究所にてAPIStudy#5が開催されました。これはAPI設計のベストプラクティスを皆で考えるというLTとワークショップの形式で行われている勉強会になります。

今回はその参加レポートになります。

APIを巡る動き

まず最初に主催であるアプレッソの脇野さんによる発表がありました。この1、2月の間にAPI関連のニュースをよく見るようになったそうです。例えば次のようなニュースがありました。

今回のAPIStudyは24人の参加で、これまでの最多となっています。とは言え元々のコンセプト通り、マニアック路線で進んでいきたいとのことです。

続いてLTの発表内容です。

こんな駅すぱあとWebサービスはいやだ by ヴァル研究所丸山さん

駅すぱあとは1988年に生まれで29年目のサービスだそうです。SDKやイントラネット版の提供により、個人利用だけでなくビジネスシーンでも数多くの採用実績があるとのことです。そして駅すぱあとWebサービスはAPIで提供されていたり、APIだけでなくサンプル（HTML5 UI）も用意されています。

そんな駅すぱあとですが、現状次のような問題点があるそうです。

APIキーが紙で届く
コピペできない…
自動発行ではない
今すぐ使いたいのに自分が使いたいときに使えない
パスが直感的ではない
/stationは駅の情報を返すんだろうと予想できる。/course/station、/course/passStationでは何が返ってくるのか分からない。
パラメータが多すぎる
仕様を読むのが大変。
JSONが使いづらい
紐付いているindexの番号が0はじまりじゃなく1はじまりになっている。配列の最初なのにindexが1。
さらに戻り値が配列だったり、オブジェクトの場合も。例えば結果が複数の場合は配列になり、1つの場合はオブジェクトになるといった具合。

これらは最初フィクションの体だったのですが、実はフィクションではなく実際の駅すぱあとAPIをベースに話されていたようです。最後にこれから自社でAPIの開発をする方にはこの失敗を踏まえていいものを作ってください、として丸山さんの話が終わりました。

ニフティクラウド mobile backend のREST API 4つの課題

次に筆者が登壇して発表しました。ニフティクラウド mobile backendというサービスのREST APIの仕様に関する話です。ニフティクラウド mobile backendというサービスはmBaaS（mobile Backend As a Service）と呼ばれるサービスで、アプリのバックエンド（サーバサイド）で必要な機能を提供するものです。

その中から4つの課題を紹介しました。まずAPIのバージョン管理で、リリース時（2013年）から変わっていません。変更タイミングは大きな問題です。

次にセキュリティで、署名生成のアルゴリズムが複雑であると、開発者が正しい生成アルゴリズムを書けているか検証するのが困難になります。実際にAPIを実行してみないと分からなかったり、エラーになった場合になぜエラーなのかが分かりづらいのが問題です。

3つ目は動的に変化するパスで、mBaaSの場合開発者の指定した名前でデータベースのテーブル相当の管理が可能になります。そのため、規定で存在しているデータと開発者が指定したネーミングによってAPIのパスが異なる仕組みになっています。統一性という意味において難点があります。

最後にドメインです。APIは開発者の利用するものと管理画面で利用するものと2種類存在します（実際にはさらに細分化されて4種類）。似たような機能を提供するAPIが作業領域の違いによってドメインを分けて運用せざるを得ないというのはとても面倒なことです。

といった形でLTの後のワークショップに繋げられるような話題を振って終了しました。

APIでダブルバッファリング by ヴァル研究所の伊藤さん

伊藤さんはレスポンスに時間がかかるAPIを巡る話を紹介されました。集計が絡むAPIになるとレスポンスを返すまでに1分以上かかる場合があり、大きな問題になります。

集計処理を実行しつつ、その結果を適宜確認したいというケースはよくあります。バッチ処理を実行して数日経ってから確認して問題がありました、ではやり直すのも大変だからです。そこで最新の集計結果を確認できるようなAPIを作成します。

しかしデータ量が膨大であるために処理時間がどんどん長くなっていきます。その内レスポンスがちゃんと返ってこなくなってしまったそうです。これは初期の想定よりも処理対象データ量が多かったという問題もあったそうです。

そこでリクエストのあったタイミングでバックグラウンドで集計処理を開始し、それまでは前回の集計結果を返すようにしたそうです。この最新の集計結果と前回の集計結果が2つのバッファリング（ダブルバッファリング）になります。

バッチ処理の集計結果を返すようなAPIではこのようなダブルバッファリングが必要になっていくのではないかとのことです。

ワークショップ

この後、4つの課題に分かれてワークショップが実施されました。今回は次の4つの議題です。それぞれのチームで話し合った結果も書いてあります。

レスポンスが遅いのにどう対応するか
一口に遅いといってもユーザの要件とすり合わせる必要があるでしょう。
APIのサポートが増加したらどう対応するか
kintoneのユーザ間サポートがよさそう。エヴァンジェリストを見つけよう。サンプルコードを充実させよう。問い合わせをAIで処理、分類分けする。営業の人たちを鍛えて簡単な質問はその場で答えられるようにする。
こんな状態は問題がある
英語対応。エラーレスポンスの形式。サポート。
複数のAPIを上手に使う方法
処理の分散と集中で解決できそう。