RESTful API Patterns & Practices • Mike Amundsen • GOTO 2024
Source: https://www.youtube.com/watch?v=etKM5-gGwto
データ中心の習慣は、システムをデータサービスの集合体としてではなく、ビジネス機能の集合体として設計することです。これは、データを証拠として捉えるこの考え方に戻ります。つまり、金を掘るようなものではなく、データは実際にビジネス機能の証拠です。私は支払いを承認したい、他の人と情報を共有したい、新しい顧客をオンボードしたい、それが私がしたいことです。データを使って必要なアクションを実行できるようにすることは非常に重要です。これは私が自己参照的な引用をする唯一の時で、ちょっと気味が悪いですが、とにかくやります。これは約10年前に私が話したことです。「あなたのデータモデルは、オブジェクトモデルではなく、リソースモデルでもなく、表現モデルでもありません。それぞれが層であり、他の層を乱すことなくその層を調整したり、置き換えたりする自由があるべきです。」これは少し挑戦的ですが、データメッセージングはその意味で重要です。なぜなら、しばしば私たちが遭遇するのは、実際にデータモデルを使用してデータモデルからAPIを生成するように指示するツールだからです。そしてそれは本当に私たちに不利益をもたらします。時には、もし私が今日自分のマシンでコマンドラインアプリを使って問題を解決しようとしているだけなら、それはおそらく良いアイデアでしょう。しかし、もし私が長期性や未来を持ちたいなら、もし私が相関のない理性的な存在と相互作用したいなら、それはおそらく良いアイデアではありません。なぜなら、そのデータ層で多くのことが変わるからです。
したがって、データストレージを隠蔽することは本当に本当に重要です。これは始める素晴らしい例です。あなたがTSQLを使っているのか、MongoDBを使っているのか、物理ファイルを使っているのか、私は本当に気にしません。アクションを実行するために必要なデータについて話し合いましょう。そして、後でそれを変更しても気にしません。階層型データベースやオブジェクト指向データベースに変更しても、datomicからTSQLに変更しても、私には関係ありません。その技術を隠蔽することは本当に重要です。技術を隠蔽することは多くの場合かなり簡単です。私はKafkaを使っています、私は使っていますが、多くの場合、クエリ言語を隠蔽することは簡単ではありません。私たちの多くはまだSELECT * FROMを行いたがるか、実際に特定の技術に非常に特化した他のことをしたがります。すべての技術とすべてのストレージの内部を確実に隠蔽することは非常に非常に重要です。
HTTPのURLの仕組みを活用することも重要です。HTTPのURLのデフォルトは、「より小さい」や「より大きい」や「グループ化」や「間」やそういった種類のものではなく、単純にこのフィールドはこの値に等しい、名前はマイクに等しい、といったものです。そして何か何かです。したがって、少なくともそのレベルでクエリ言語を実装することは非常に非常に強力です。背後に非常に強力なデータツールがあるかもしれませんが、もしこの値がある情報を約束するだけなら、例えば名前がMiに等しいならマイクを返すでしょう。なぜならMiが含まれているからです。そうすれば非常に非常に強力です。
クエリのメタデータを返すことも、特に内部側では重要です。特に内部側で情報クエリを行っている場合、情報検索クエリを行っている場合、データ更新やデータ管理クエリではなく、アムステルダムでのgotoに関連するすべてのレコードが欲しい、という場合、それは何年にもわたって数百、数百、おそらく数千のレコードになる可能性があります。私が探しているものによっては、本当にわかりません。だから多くの場合、前もって知る必要があります。最初の100件を提供しますが、約11,000件あることを伝えます。クエリを絞り込む必要があるかもしれません。または、可能な返答が非常に多いので、実際に取得を開始しないでください。クエリを絞り込む必要があります。これはメタデータとメタ情報を共有する際に起こります。
アプリケーションで働く私たちにとっての典型的なケース、クエリが何もレコードを返さない場合、私のHTTP値は200ですか400ですか？200と言う人？400と言う人？空のページです。誰もそれに引っかからなかったようですね。しかし、何度も何度もパターンを持つこと、メッセージの観点から考えると、1つのレコードがあろうが500のレコードがあろうが、レコードがなかろうが、毎回メッセージが返ってくるので、それが200である意味があります。
場合によっては、実際にクエリのためのメディアタイプを使用することができます。非常に長く複雑なクエリは、HTTPラインに載せるのが本当に難しいです。実際にかなり複雑な一連のステートメントが必要です。実際にTSQLメディアタイプがあり、10年以上前に登録されています。そのため、実際にSQLメッセージをHTTPを介してポストボディやさらには更新、プットボディで送受信することができます。
Solarや他の種類のシステムを使用したことがある人はどれくらいいますか？そうですね、Elastic Searchなど。それらにも独自の言語があり、メディアタイプに変換して、HTTPメッセージを介して相当複雑なSolarやElastic Searchのクエリを送信することができます。
最後に、キャッシングによってデータを改善する方法がいくつかあります。本番環境でのデータの変更、本番環境でのモデルの変更は頻繁に起こります。突然フィールドを追加したい場合、これまで2つのテーブルにあったものを今後3つのテーブルに移動したい場合、何が起こるでしょうか。物事を壊すことなくそれを行う必要があり、元に戻せるようにする必要があります。もし考えを変えたら、古いモデルに戻れるようにします。リモートデータストアの拡張、私はSalesforceと作業していて、彼らが私のために何か情報を提供していますが、いくつかの追加フィールドが必要です。実際にはSalesforceはそれを許可していますが、他の製品は許可していないかもしれません。HubSpotやWorkdayでは、自分のデータベースを作成し、それを彼らのものに接続する必要があります。戻ってくるすべてのクエリに対して、私のデータを添付する必要があります。そうすれば、私のユーザーがその情報を使用できるようになります。これは拡張の素晴らしい例です。大規模な応答を制限することについて先ほど話しました。そして、パススループロキシもあります。
リアルタイムでモデルを変更することはかなり一般的です。これが私のメッセージです、これが私のデータです。家族名と名前に加えてミドルネームも追加する必要があることがわかりました。しかし、このデータベースはおそらくHubSpotやWorkdayが所有しています。彼らのデータを変更することはできません。そこで、自分の名前と値のペアのサイドカーテーブルを作成し、個々のレコードに関連付ける必要があります。これで、その情報を追跡できるようになります。実際に、この情報を全員に公開するかもしれません。一部がサイドカーからで、一部が他のソースからであることを知る必要はありません。これは、他の人を巻き込むことなくデータを拡張する強力な方法です。
ベゾスの「すべてがAPIであるべき」という話を知っている人はいますか？誰か知っていますか？ベゾスはこの考えでAWSを始めました。すべてがAPIになり、APIとしか話せず、もはやソフトウェアの人々の背後で話すことはできません。人々はこれが主にマイクロサービスの作成に関する何らかの建築的な理解に関係していたと考えています。90年代にこのメッセージを宣伝した時、マイクロサービスのようなものは存在しませんでした。彼が試みていたのは、人々に会議を止めさせることでした。会議を開かないでください。高価な建築家たちを集めて、あなたのデータベースにミドルネームフィールドを追加すべきかどうかについて議論しないでください。他の誰もそれを望んでいないのです。ただ一つのチームが、自分でそれを追加すればいいのです。はい、そうです。それが本当にそのパターンが来た場所です。
データを移植可能にすることは本当に強力です。ワークフローについて話しましょう。生産性は決して偶然ではありません。それは卓越性への取り組みの結果です。ポール・J・マイヤーはモチベーショナルスピーカーのタイプです。私はこの引用が好きです。なぜなら、物事がうまく機能するためには努力が必要だという考えがあるからです。そして、それが本当にワークフローの全てです。
ワークフローは本当に本当に難しいです。私たちが試みているのは、他のサービスを何らかの組み合わせ可能な方法で活用して、各個別サービスが知らないかもしれないことを達成することです。私にはタスクとジョブの共通のパターンがあり、それらを達成する必要があります。そして、私のタスクとジョブがどのように進んでいるかを知るという考えがあります。
ワークフローには多くのパターンがあります。本の中ではそのうちの多くについて話す機会はありませんが、その多くはワークフローコンプライアンスサービスがどのようなものか、どのような機能を持っているかという考えを持っています。HTTPリソースにはget、put、post、deleteなどがあることを知っています。これは一種のパラダイムです。これはパターンです。コンプライアンスサービスのパターンは何でしょうか？コミットする必要があります。ロールバックする必要があります。キャンセルする必要があります。やり直す必要があります。一連のステップがあり、これらのメッセージの一部がそれについて話しています。
ワークフローの共有状態も本当に重要です。もし私が会ったことのないサービスを活用している場合、状態はどこに行くのでしょうか？時にはクライアント上にありますが、時には複数のクライアントがあります。状態を共有する方法を考える
状態を共有する方法を考えるには様々な方法があります。ワークフローをコードとして記述することは、私たちのほとんどがそうしているように、このサービスを呼び出し、そのためのコードを書き、そしてそのサービスからデータを取得して別のサービスに渡し、その結果からデータを取得して別の場所に渡すというものです。私たちはコードを書きますが、時にはドメイン特化言語を作成します。バレリナという言語を聞いたことがありますか？バレリナは、このワークフローやインターコネクション、統合という概念のために特別に設計された言語です。彼らがそれをバレリナと呼んだのが大好きです。なぜなら、彼らは振付をするからです。サービス振付について知っている人がいれば、それはバレエのようなものです。
また、ワークフローをドキュメントとして持つこともできます。請求書や書類のようなドキュメントを世界中に渡すことができます。または、独自の種類のジョブ制御言語を作成することもできます。私は、いくつかの異なるフォーマットで学んだRESTfulジョブ制御と呼ばれるものの例を挙げます。それをすぐに見てみましょう。
そして、日常的なことがたくさんあります。進捗状況をどのように知るか、完了したか、半分終わったか、何かが詰まっているかなどです。今この瞬間に可能なことは全て何か、全てのアクションを返すこと、最近使用したアクションは何か、チケットを開く人はしばしば次のステップとして誰かに作業を割り当てたいと思うので、その情報を前もって送ることで、クライアントが特定の問題を解決しやすくします。
進行中の状態のある作業をサポートすること、画面に5つか6つの異なるタブがあるような場合、それを前もってどのようにサポートするか、最終項目を最終的に送信するまで、ステップバイステップの状態のあるものをどのように作成するかなどです。
リストナビゲーションの確立、部分的なフォーム送信について話しました。これは非常に強力です。5つの入力が必要で、3つを提供した場合、入力を拒否するのではなく、その3つを受け取り、さらに2つを提供してくださいと言います。これは、このような技術を使用して非常に強力な自動化ボットを作成できることを意味します。
クライアントワークフローを可能にする状態のあるパターンは、クライアントに自分の時間を管理させるという考えです。おそらく彼らは部屋の温度に注意を払っており、その仕事は特定の温度を維持することです。クライアントが建物のさまざまな場所の温度がどうなっているかについて十分な情報を与えることで、物事をオンにしたりオフにしたりする時期を決定させます。
そして、リプレイや未完了の作業、自動リトライやロールバックについていくつかの最適化があります。これらの一部については以前に話しました。しかし、それらをレシピやパラダイムとして作成することは、一般的な方法でそれらについて話すことができることを意味します。
さて、これが先ほど話したジョブ制御言語です。ホームから始めてジョブのリストを取得し、ジョブを実行してさまざまなステップを行うことができます。そしてすべてがうまくいっていれば成功し、そうでなければロールバックします。
ワークフローを柔軟にすることは非常に重要です。それは実際にメタデータです。ワークフローを可能にするだけでは十分ではなく、他の人がワークフローを作成できるようにすることが重要です。これは非常に挑戦的です。
さて、まとめましょう。ここに含まれているすべてのことは、実際にこのRESTfulの原則に従っています。これは長い間私が持ち続けてきたものであり、すでにさまざまな方法で言及しているのを聞いたと思います。グローバルな到達範囲、インターネットを活用して、あなたが考えたことのない問題を、あなたが会ったことのない人々のために解決すること。
そして考えてみてください。それが良いソフトウェアがすることです。それが表計算ソフトウェアがすることです。表計算ソフトウェアは、表計算ソフトウェアの作成者が数十年にわたって会ったことのない人々が、彼らが考えたことのない問題の解決策を作成することを可能にします。それが私たちがしたいことです。
良いレシピや良いパターンを考える様々な方法があります。ソリューションを自分で共有し、他の人のソリューションを見つける能力。それらを他の人が使えるようにすること。あなたが考えていない方法で。それらを拡張させること、他のことをさせること。それらを閉じ込めないこと、創造的になることを妨げないこと。見知らぬ人が安全かつ成功裏に問題を解決するために相互作用できるようにすること。なぜ全員にロールバックを与えるのですか？彼らは何かを試してみて、気に入らなければそれをロールバックできます。そして、長期性と独立した進化を促進するという考え。私が他の全ての人を心配することなく自分のサービスを変更できるようにすること。
最後に、時間が実際に建築要素であることを理解するという考え。多くの時間がかかります。時間とともに物事は変化します。優先順位は時間とともに変化するので、私たちのサービスも変化できる必要があります。
これらのことについて話しました。それぞれについて、最後にもう一つのメッセージを残します。ドネラ・メドウズからのメッセージです。彼女は「システムで考える」という素晴らしい本を書きました。世界について知っていると思っているすべてのことは、ただのモデルに過ぎません。コルジブスキーの「地図は領土ではない」という別のフレーズがあります。
この考え、つまりモデルが世界を見ることを可能にし、そのモデルを変更したり、他のモデルを作成したり、他の人とモデルを共有したりできるという考えです。そしてそのようにして、私たちは実際に世界がどのように見えるかを変えることができます。特にこれらのパラダイムやパターンの観点から考えるときに、他の人々が自分の問題を創造的に解決することを可能にし、具体的なことではなく、他の人々が驚くべきことをするための力を与えることができます。
そして、これが今日私が皆さんにお話ししたことです。ありがとうございました。[拍手]