APIStudy#7 開催報告

Avatar
dstn

 

こんにちは。對馬です。

APIStudy 運営事務局の對馬です。

 

4月21日にVALUESさんのオフィスにて開催された、APIStudy #7の様子をご報告します。

IMG_1977.JPG

前回#6の開催報告はこちらからどうぞ!

 

 

第1部:LTタイム

 

本日のLTは会場を提供していただいたVALUESさんから2名、お話しいただきました。

 

厚地さん

IMG_1968.JPG

VALUESさんが提供しているインターネット行動ログ分析サービス eMark+のAPIに関するお話。

そのサービスのフロントとサーバーの内部処理にAPIを活用しています。

 

フレームワーク使ってません!

ピュアJavaに近いです。

 

クエリが複雑、書いたほうが楽。

ひねった処理も書いたほうが楽。

 

ただ、APIが100個越えてきてメタ情報の管理が大変なので、効率的にやれるようないい方法があれば…。

 

eMark+では、Redshiftにある40億とかのでかいデータを検索して抽出しています。

1発では返せないので、定期的に処理終わったかポーリングして、終わったら表示されるようにしています。

 

ポイントとして、データ抽出のAPIという概念の上で「リクエストを送る」のと「結果取得」の2つにAPIを分けている。

これのベストプラクティスないかな!

 

 

斎藤さん

IMG_1956.JPG

「APIの一斉テストをしてみた」というテーマでお話しいただきました。

 

全APIのテストをしました!

  • 500エラーがないか。
  • APIとして通信した時に200がちゃんと返ってくるか。
  • ELBのスティッキーセッション機能がちゃんと動いているか。
  • 性能改善されているか。

 

活用したツール!

  • jasmine
    • JavaScript のテストフレームワーク
    • https://jasmine.github.io/Node.js 

 

  • Frisby
    • REST API のテストフレームワーク
    • http://frisbyjs.com/ 

 

JavaScriptで書けるのでかなり柔軟に書ける。

APIのレスポンスタイムも出力できる。

Cookieを用いてログイン後のテストもできる!

レスポンスの出力もできる。

 

 IMG_1961.JPG

IMG_1964.JPG

画面を見ながら操作感を紹介していただきました! 

 

 

第2部:ディスカッションタイム

 

LTが終わるとディスカッションタイムです。

これまでは、第1部の内容をもとにテーマを決め、ディスカッションを行ってきました。

が!今回は新しいディスカッション方法を試してみる!ってことで、これまでと手順が変わりました。

 

手順としては、まずはチームを作ってもらい、そのチーム内で「APIで経験したベストプラクティス」について紹介しあいます。

チーム内での発表が終わったら、その中で掘り下げたいベストプラクティスを決め、ディスカッションしていきます。

ディスカッションが終了したら、全体で発表してもらいます。

 IMG_1983.JPG

IMG_1985.JPG

 

今回は3チームに発表してもらいました。

 

Swaggerチーム

IMG_1993.JPG

Swagger…。よさそうだけど既存APIの対応とか大変じゃない?という声がチーム内で挙がり、StopLightがいいよ!という提案がありました。

 

StopLightのコンポーネントであるPrism(プロキシサーバー)ができることとして、クライアント・サーバー間の通信をログに取っておいて、Swaggerのページで出力を行います。

また、APIのサーバーサイドを模擬したり、ドキュメントをポスティングもしたりできます。

IMG_1992.JPG

結論:webMethods高機能

 

 

REST APIチーム

IMG_1995.JPG

サイボウズさんの話から。

出力もいろんなパターンあるが、RESTでJSONを使っています。

それは「楽になるから」という理由だそうです。

というのも、企業のAPIは広がらないと意味がないため、可読性がよかったり楽だったりということが重要です。

なので、新しい技術出てきたらどんどん使っていきます。

 

逆に、基幹システムとつながっているものだと、こまめに変えることができないためSOAPとか古い技術が適切となります。

 

あとは、ノンコーディングでAPI!

API×APIの組み合わせについてですが、これがNode-RED、MESHみたいにAPI同士をコネクタでつなげられたら楽だな。

そうなるとMashupとかも楽になるし、社内APIとかの場合でも活用できます。

 

またコネクタを使っても、カスタマイズするときにソースコードを書く必要が出てくるはずで、それもGithubみたいな、新しいコネクタとしてみんなで共有できたら理想的。

 

誰かスタートアップしませんか?

 

Swaggerチーム「Swagger hub※とかあるよ!」って後ろから言ってました。

https://swaggerhub.com/

 

 

イケてるAPIチーム

IMG_2002.JPG

エンジニア目線からの行けてるAPIはこれだ!

 

  • すぐにたたける!
    • コピペでカール最強。
  • SDK自動生成。
    • エンジニア超楽。
  • 人が読める
    • サポートのときとかを考えると、ヒューマンリーダブルが理想。
    • でもAWSはメタデータばかりのマシーンリーダブル!相反するから疑問符あるけど、エンジニアとしてはヒューマン希望。

 

すぐに叩けるAPIといえば…、決算系のソフトバンクペイメントゲートウェイでは、すぐにたたける準備がされているので、非常に捗ります。という紹介が。

↓このサービスかしら…。

https://www.sbpayment.jp/service/connection/api_system/

作る側のみなさんは参考にしてみるとgoodかもです!

 

 

おわりに

無事に終了してよかったです!

まず今回のグラレコ!

IMG_2007.JPG

VALUESカラーの緑で描かれていて、とてもわかりやすいですね。

ありがとうございます!

 

そして、APIStudyの開催もおかげさまで半年を越えました。

新しくなったディスカッション形式のように、これまで発散してきた情報をまとめて「APIのベストプラクティス」に近づいていきたいと思います。

 

 

次回開催

 

長らくお待たせいたしましたが、ついに次回開催が決定しました。

 

次回は5月30日(火)、株式会社アプレッソで開催します!

第8回もお楽しみに!

 

 

よろしくお願いします! 

 

 

コメント

ログインしてコメントを残してください。

Powered by Zendesk