『Webを支える技術』を読んで ― Power Platformに見るRESTとWebの設計思想｜分析屋

RESTとHTTPの関係

REST（Representational State Transfer）は、アーキテクチャスタイルです。WebはこのRESTに基づいて設計され、その実装技術としてHTTPが選ばれました。

RESTは6つの制約（クライアント/サーバー、ステートレス、キャッシュ、統一インターフェース、階層化システム、コードオンデマンド）を組み合わせて定義されています。それぞれは単純な制約ですが、それを徹底することで拡張性と持続性を兼ね備えたシステムを作ることができています。
HTTPは、この制約を体現するシンプルなプロトコルです。典型的なリクエストとレスポンスは以下のようになります。

【リクエスト】

GET /_api/web/ HTTP/1.1
Host: contoso.sharepoint.com
Authorization: Bearer 
Accept: application/json;odata=verbose

【レスポンス】

HTTP/1.1 200 OK
Content-Type: application/json;odata=verbose

{
  "d": {
    "Title": "サイト名",
    "Url": "https://contoso.sharepoint.com/sites/sample"
  }
}

ここで重要なのは、ヘッダーの付加情報でデータの解釈方法を決めていること、また、リソースをURIで一意に識別していること、です。私達がリクエストをWebに向けて送信する際、求めているのはレスポンスの中の「body」、つまりJSON形式のデータです。しかし、RESTの本質を支えているのは、むしろヘッダーのほうだと言えます。まずはこちらについて見ていきます。

Power Automateに見るRESTの痕跡、ヘッダー

Power Automateでコネクタ（API）を呼び出すと、結果は必ず「headers」と「body」に分けられて表示されます。多くの場合、後続のアクションで使用するのは「body」だけです。事実、あるアクションによって取得されたデータを後続のアクションへ渡す際に用いられる「動的なコンテンツ」は、「body」に含まれるものだけです。

しかし、REST や HTTP の考え方を踏まえると、このときのヘッダーを軽視してはいけないことがわかります。Content-Typeがapplication/jsonを示しているからこそ、クライアントはボディをJSONとして解釈します。もし、このヘッダーがapplication/xmlであれば、同じボディのデータをXMLとして解釈します。つまり、ボディはヘッダーなしでは意味を持たないのです。

例えば、Power Automateの[SharePointにHTTP要求を送信します]アクションにおいて、_api/web（当該サイトのすべてのリソースの一覧を取得する）に向けて、GETリクエストを送信してみます。

Acceptヘッダー（クライアントが要求するリソースの形式を指示するためのヘッダー）をapplication/jsonにして取得した結果は、以下の画像のようになります。

一方、次の画像では、Acceptヘッダーをapplication/xmlとしてリクエストした出力結果です。自分が欲しい形式を伝えれば、（その表現が可能であれば）Webは答えてくれます。

Power Automateでは、標準コネクタのほとんどは基本的にJSONでデータを取得し、クライアントへレスポンスを返す仕組みになっていますので、HTTPヘッダなど、Webの知識を理解しなくても使えます。しかし、その裏ではRESTの原則がしっかりと生きているのです。

URI とリソースの関係性

RESTのもう一つの大きな特徴は「リソースはURIで一意に識別される」という原則です。上でも使用したPower Automateの[SharePointにHTTP要求を送信します]アクションは、この考え方を理解するのに特に役に立ちます。
たとえば次のURIを指定してリソースをGETするHTTPリクエストを送信すると、サイトコレクション配下のすべてのリストを取得できます（サイトのページなどもここに含まれます。）。

/_api/web/lists

さらに、特定のリストを取得したい場合は以下のように指定します。

/_api/web/lists/GetByTitle(‘Tasks’)/items

このようにURIをたどっていけば、自分が必要とするデータに直接アクセスできます。Power Automateの「動的なコンテンツ（トークン）」は非常に便利で、トリガーやアクションが裏で何をしているのかをユーザーが意識する必要はありません。

ただ、ここを通り過ぎずによく観察してみると、実はその裏側では、サイト名やリスト名などの情報がリソースのURIに変換され、HTTPリクエストが行われていることが感じられるのです。
こう見ると、Web をリソースの集合として捉えるRESTの思想が、そのままPower  Platformの設計思想にも反映されていることを感じます。

Power AppsのMSAPPファイルに見る「リクエストの単位」

一方で、Power AppsのアプリはWeb ページとは異なる性質を持っています。アプリの中に複数の画面を作成できますが、それぞれの画面に固有のURIが割り当てられているわけではありません。

アプリ全体がMSAPPファイルという1つのリソースとして扱われているからです。利用者がアプリを起動すると、このMSAPPファイルに対してリクエストが1回送られます。その後の画面遷移はHTTP的な「リソースの移動」ではなく、アプリ内部の「状態遷移」として処理されます。

そのため、Webのようにhttps://example.com/page1とpage2のように直接画面のURIを指定してアクセスすることはできません。代わりにPower AppsではParam関数を利用し、URIに付加されたパラメータから値を受け取ります。そして、その値をもとに初期表示する画面やデータを制御します。これは、画面単位でのURIを持たないPower Appsにおいて、Webページと同様のURIの粒度を補完する仕組みだと考えることができます。

「アプリ＝リソース」という考え方は、Webの「ページ＝リソース」とは異なりますが、RESTの枠組みを理解していると、なぜそうなっているのかも理解できます。

Web を理解して Power Platform を理解する

ここまで見てきたように、『Webを支える技術』が示すRESTの思想は、Power Platformを深く理解するうえで非常に重要です。

• ヘッダーとボディの役割分担は、Power Automateの出力を見ると実感できます。

• リソースとURIの一意性は、SharePoint APIを直接呼び出すことで理解できます。

• リクエストの単位は、Power AppsのMSAPP構造に置き換えて考えると見えてきます。

私たちが普段何気なく利用しているクラウドサービスも、裏側ではHTTPリクエストとレスポンスが飛び交っています。その仕組みを理解することで、ツールを「使う」だけでなく、「設計思想に踏み込んで理解する」ことが可能になるのではないでしょうか。

おわりに

RESTはWebを成功に導いたアーキテクチャスタイルであり、シンプルでありながら堅牢な仕組みを提供します。その実装であるHTTPは、Power Platformをはじめ、あらゆるクラウドサービスの基盤にも存在しています。

今回、『Webを支える技術』を読み、得られた知識をPower Platformの実務と結びつけることで、抽象的な原則と具体的な実装の両面から理解を深めることができました。

技術を単なる道具として覚えて使うのではなく、その背後にある概念をも理解することの面白さを、今後も書いていければと思います。

ここまでお読みいただき、ありがとうございました！
この記事が少しでも参考になりましたら「スキ」を押していただけると幸いです！

---

株式会社分析屋について

弊社が作成を行いました分析レポートを、鎌倉市観光協会様HPに掲載いただきました。

ホームページはこちら。

noteでの会社紹介記事はこちら。

【データ分析で日本を豊かに】
分析屋はシステム分野・ライフサイエンス分野・マーケティング分野の知見を生かし、多種多様な分野の企業様のデータ分析のご支援をさせていただいております。 「あなたの問題解決をする」をモットーに、お客様の抱える課題にあわせた解析・分析手法を用いて、問題解決へのお手伝いをいたします！

【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。

【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。

【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。

【SES】
SESサービスも行っております。