こんにちは。對馬です。
APIStudy 運営事務局の對馬です。
4月21日にVALUESさんのオフィスにて開催された、APIStudy #7の様子をご報告します。
前回#6の開催報告はこちらからどうぞ!
第1部:LTタイム
本日のLTは会場を提供していただいたVALUESさんから2名、お話しいただきました。
厚地さん
VALUESさんが提供しているインターネット行動ログ分析サービス eMark+のAPIに関するお話。
そのサービスのフロントとサーバーの内部処理にAPIを活用しています。
フレームワーク使ってません!
ピュアJavaに近いです。
クエリが複雑、書いたほうが楽。
ひねった処理も書いたほうが楽。
ただ、APIが100個越えてきてメタ情報の管理が大変なので、効率的にやれるようないい方法があれば…。
eMark+では、Redshiftにある40億とかのでかいデータを検索して抽出しています。
1発では返せないので、定期的に処理終わったかポーリングして、終わったら表示されるようにしています。
ポイントとして、データ抽出のAPIという概念の上で「リクエストを送る」のと「結果取得」の2つにAPIを分けている。
これのベストプラクティスないかな!
斎藤さん
「APIの一斉テストをしてみた」というテーマでお話しいただきました。
全APIのテストをしました!
- 500エラーがないか。
- APIとして通信した時に200がちゃんと返ってくるか。
- ELBのスティッキーセッション機能がちゃんと動いているか。
- 性能改善されているか。
活用したツール!
- jasmine
- JavaScript のテストフレームワーク
- https://jasmine.github.io/Node.js
- Frisby
- REST API のテストフレームワーク
- http://frisbyjs.com/
JavaScriptで書けるのでかなり柔軟に書ける。
APIのレスポンスタイムも出力できる。
Cookieを用いてログイン後のテストもできる!
レスポンスの出力もできる。
画面を見ながら操作感を紹介していただきました!
第2部:ディスカッションタイム
LTが終わるとディスカッションタイムです。
これまでは、第1部の内容をもとにテーマを決め、ディスカッションを行ってきました。
が!今回は新しいディスカッション方法を試してみる!ってことで、これまでと手順が変わりました。
手順としては、まずはチームを作ってもらい、そのチーム内で「APIで経験したベストプラクティス」について紹介しあいます。
チーム内での発表が終わったら、その中で掘り下げたいベストプラクティスを決め、ディスカッションしていきます。
ディスカッションが終了したら、全体で発表してもらいます。
今回は3チームに発表してもらいました。
Swaggerチーム
Swagger…。よさそうだけど既存APIの対応とか大変じゃない?という声がチーム内で挙がり、StopLightがいいよ!という提案がありました。
StopLightのコンポーネントであるPrism(プロキシサーバー)ができることとして、クライアント・サーバー間の通信をログに取っておいて、Swaggerのページで出力を行います。
また、APIのサーバーサイドを模擬したり、ドキュメントをポスティングもしたりできます。
結論:webMethods高機能。
REST APIチーム
サイボウズさんの話から。
出力もいろんなパターンあるが、RESTでJSONを使っています。
それは「楽になるから」という理由だそうです。
というのも、企業のAPIは広がらないと意味がないため、可読性がよかったり楽だったりということが重要です。
なので、新しい技術出てきたらどんどん使っていきます。
逆に、基幹システムとつながっているものだと、こまめに変えることができないためSOAPとか古い技術が適切となります。
あとは、ノンコーディングでAPI!
API×APIの組み合わせについてですが、これがNode-RED、MESHみたいにAPI同士をコネクタでつなげられたら楽だな。
そうなるとMashupとかも楽になるし、社内APIとかの場合でも活用できます。
またコネクタを使っても、カスタマイズするときにソースコードを書く必要が出てくるはずで、それもGithubみたいな、新しいコネクタとしてみんなで共有できたら理想的。
⇒誰かスタートアップしませんか?
Swaggerチーム「Swagger hub※とかあるよ!」って後ろから言ってました。
イケてるAPIチーム
エンジニア目線からの行けてるAPIはこれだ!
- すぐにたたける!
- コピペでカール最強。
- SDK自動生成。
- エンジニア超楽。
- 人が読める
- サポートのときとかを考えると、ヒューマンリーダブルが理想。
- でもAWSはメタデータばかりのマシーンリーダブル!相反するから疑問符あるけど、エンジニアとしてはヒューマン希望。
すぐに叩けるAPIといえば…、決算系のソフトバンクペイメントゲートウェイでは、すぐにたたける準備がされているので、非常に捗ります。という紹介が。
↓このサービスかしら…。
https://www.sbpayment.jp/service/connection/api_system/
作る側のみなさんは参考にしてみるとgoodかもです!
おわりに
無事に終了してよかったです!
まず今回のグラレコ!
VALUESカラーの緑で描かれていて、とてもわかりやすいですね。
ありがとうございます!
そして、APIStudyの開催もおかげさまで半年を越えました。
新しくなったディスカッション形式のように、これまで発散してきた情報をまとめて「APIのベストプラクティス」に近づいていきたいと思います。
次回開催
長らくお待たせいたしましたが、ついに次回開催が決定しました。
次回は5月30日(火)、株式会社アプレッソで開催します!
第8回もお楽しみに!
よろしくお願いします!