見出し画像
Photo by narukuni

イベントドリブンのAPI

Sachiko Kijima

イベントドリブンアーキテクチャってなんだっけの前段として、そもそもイベントドリブンのAPIってなんだっけという話。

「ドリブン (driven)」があちらこちらで使われていて、日本語訳では「駆動型」と言われることが多いですが、「〜を中心とした」と言った意味で理解するとそれっぽいです。今回の場合は「イベント中心の」。

イベントドリブンAPIはよくIoTで使われます。

イベントドリブンのAPIとは

APIクライアントの近くで起こった事象をサーバーに伝達するためのAPIのこと。
例えば通常のRESTであれば、リクエストはレスポンスを得るためのものだったりするので、あくまでリクエストとレスポンスが対になります。
が、イベントドリブンのAPIはサーバーに対してどこで何が起こったかを伝達することが目的になるので、サーバーに確かにデータが届いたかどうかの確認のためには必要だけど、レスポンスの内容は特に必要じゃない。

画像1

こんな感じでAPIサーバーに対してデータを送付し、後ろのレシーバーで何らかのアクションを起こします。
レシーバーは何台でも追加できるのが特徴。

何が起こったかを伝達するものなので、Bodyの中身が起こった事象の説明になっていることが多いです。例えば、

{
   “date”: “2020/9/22 9:30”,
   “event”: “Memo Added”,
   “source”: “iPad”,
   “desc”: .....
}

みたいな感じです。

ただし上記はRESTで実装する場合で、IoTのAPIではHTTPではないAPIのプロトコルもあります。MQTTとかCoAPとか。
この辺りになってくると「何バイト目が7なら何の意味で」のように、人が見てもわからないデータとして伝達するようなプロトコルになっています。

例: Amazon Dashボタン

Amazon Dashボタンはこの代表と言えます。おわっちゃったけど。

画像2

Amazon Dashボタンはボタンしかないですよね。
ポチッと押されたことがサーバー側に通知されます。APIの通信としてはそこでおしまい。HTTP的なレスポンスがあっても、人にはわかりません。

そのかわりAPIサーバーの後ろにレシーバーがいて、ボタンが押されたことを受信すると、
- 該当のAmazon Dashボタンに関連づけられた製品を確認
- (多分) 発注履歴に発注を登録
- 梱包して発送
を実施します。これレシーバーがそのように手配してるんですね。

例: ビールの温度管理

ビールとIoTの組み合わせで見かけるのはビールの製造工程やデリバリ、お店などでIoTを使って温度管理をし、温度が上がってきてしまいそうであればアラートを出して人に対処してもらうとか、あるいは自動で冷蔵庫の温度を下げるとか。
アメリカだかの飲み屋さんでIoTで温度管理と在庫管理をして、ビールの在庫が減って来たら自動で発注とかをやっているよ〜という話も聞いたことがあります。

ここが読んだ中では詳しかった。これは温度などを通知してアプリで人に見せるようなソリューションだと思います。

APIの話で言うと、温度管理で言えば一定時間に一回、温度計から温度を吸い上げてAPIで送るんですね。
で、サーバー側で吸い上げられた温度データから、どこにどんな対処が必要かを判断したり、集約データをアプリに表示させたりしています。

例: スシロー

これもそうです。Amazon Kinesisだし。

スシローではお皿の後ろにチップを仕込み、お寿司のレーンの上の「マグロ」などのパーティションとお寿司の位置関係で、そのお皿がどのネタのお寿司なのかを判断しているそうなんですね。
で、どこかの席でピックアップされたら「食べたな」ということでイベントをAmazon Kinesisに送っているそうです。

送られたデータはサーバーがわで集約されて統計データになり、需要予測とかすしネタの発注量の元データになるそうです。

この、チップの動きがあったことを検知してAmazon Kinesisにデータを伝達する部分がイベントドリブンのAPIの役割です。

まとめ

- APIクライアントからサーバーへの通知を目的としたAPI
- IoTでよく使われます
- レシーバーが複数置けるしいつでも増やせるのが特徴

というところで次にやっと本題のイベントドリブンアーキテクチャに行きたいと思います。

この記事が気に入ったらサポートをしてみませんか？