技術記事
注文APIがどこにも見当たらない中で、GrubhubとDoorDashの注文確認がどのようにネイティブなDinDin注文になったのか。
プロダクトが依存するシステムに公開APIが存在しない場合、そのインターフェースがプログラムではなく人間向けに設計されたものであっても、実際に公開されているインターフェースに対してインテグレーションを構築するしかありません。コネクテッドレストラン向けテクノロジースイートであるDinDinの場合、そのインターフェースとは受信トレイでした。
実績の読み方
DinDinのレストラン顧客は、自社サイト、自社のPOS、サードパーティの配達マーケットプレイスなど複数のチャネルから注文を受けており、そのすべての注文が同じキッチンプリンター、同じレポーティング、同じ業務ワークフローへとたどり着く必要があります。GrubhubとDoorDashの注文はそこに空いた穴でした。いずれのマーケットプレイスも、このワークフローに必要な注文APIを公開していなかったのです。各マーケットプレイスが確実に送ってくるのは、レストラン自身の受信トレイ宛のHTML形式の注文確認メールであり、それはマネージャーが手作業で読むのと同じメールでした。
実績の読み方
このパイプラインは共有の受信トレイに認証し、届く確認メールの一通一通をインテグレーション面として扱います。すなわち、HTML形式の注文確認メールを解析し、それがどの加盟店のものかを特定し、DinDinのネイティブな注文モデルへと注文情報を抽出します。ここから先は、レストラン自身のサイトで受けた注文と区別がつかず、同じキッチンプリンターと同じレポーティングに流れます。このような認証済み受信トレイインテグレーションが一般にどのように構築されるかについては、Gmail APIが妥当な参照例となります(後述のGmail APIガイドを参照)。
実績の読み方
メールベースのインテグレーションは、再実行に耐えられる必要があります。取得の途中で接続が切れることもあれば、同じメッセージが再処理されることもあるからです。このパイプラインは、自由記述のテキスト内容から識別子を導出するのではなく、各マーケットプレイス自身の注文番号によって重複を排除しているため、同じ確認メールを再処理しても二枚目のキッチンチケットが作成されることはありません。これは、決済API設計で文書化されているのと同じ冪等リクエストの規律であり、そこではクライアント側で指定した識別子を使うことで、リトライされたリクエストが二重課金や二重作成を引き起こさないようにしています(後述のStripeの冪等リクエストに関するドキュメントを参照)。
実績の読み方
この一般的な教訓は、レストランやメールに限った話ではありません。あるシステムがAPIを公開していない場合、たとえ人間向けに作られたものであっても、そのシステムが実際に公開している中で最も安定したインターフェースに対してインテグレーションを構築し、正式なAPIインテグレーションと同じ重複排除の規律によって再実行を安全にするのです。ここでの受信トレイは単なる次善策ではなく、適切な規律をもって扱えば、それ自体がインテグレーションなのです。
リファレンス
Written by
AI/MLアーキテクチャ、技術戦略、プラットフォームアーキテクチャ、エンジニアリングリーダーシップ、システムインテグレーション、セルフホスト型AI。
同じような課題を抱えていますか？
プラットフォームの変更が遅く、危険になってきたSaaS創業者・エンジニアリング責任者向け。
アセスメントを依頼するLet's build what's next
アイデアの段階でも、既存プラットフォームの刷新でも、システムの拡張でも、まずはご相談ください。
Better Technology.
Brighter Possibilities.
