💥 💢 🎅🏼 現実世界のRESTとハイパーメディアの実践 ✋🏽 🎡 👏🏻

RESTの詳細を考慮して、アプリケーションのアーキテクチャを構築する方法は？「REST」という言葉は、HTTP APIを無差別に指すこと、そしてこの用語の本当の意味をどのように伝えるか、ということですか？ RESTの利点が大規模な長期プロジェクトに現れることを示す方法はありますが、小規模なユーティリティの場合は、もっと単純なものを採用する方が良いでしょうか。これらの問題およびその他の書き込みの問題は、Dylan BeattieがReal world REST and Hands-On Hypermediaというタイトルのレポートで強調しています。

Dylanは、小さなウェブサイトから巨大な分散システムまで、人生の間にさまざまなプロジェクトに参加したシステムアーキテクトおよび開発者です。 20年の歴史を持つレガシーから最新の開発まで。現在、 Spotlightのアーキテクトとして働いており、今日の分散システムの複雑な課題に取り組んでいます。適切で美しく効率的なHTTP APIを作成することは彼の仕事の一部であり、彼はそれらについて本当に多くのことを知っています。

Dylanは、 2017年のDotNext Moscowカンファレンスでライブで会うことができます。Dylanは、新しいレポート「人生、自由、APInessの追求：幸せなコードの秘密」を受け取ります。 10月31日までチケットをおいしい価格で購入できることをお知らせします。

この記事をテキストデコードで読む（「もっと読む」ボタン⇩をクリックする）か、完全なビデオレポートを見ることができます。理解に必要なすべての画像、スライド、図は、ビデオとテキストデコードの両方に存在するため、何も失われません。

記事へのコメントは大歓迎であり、非常に重要です。DotNextMoscow 2017で Dylanに直接最高の質問をするようにします。

今日は、現実世界のRESTイデオロギーとハイパーメディアの実用的な具体化についてお話します。

しかし、最初に、私について少し。

私の名前はディラン・ビーティーです。レポートに関する質問をする最良の方法は、twitter（@dylanbeattie）で私を見つけることです。 VKページは持っていますが、ロシア語は話せません。そのため、このソーシャルネットワークには友達がいません。

長い間、私はウェブサイトを作成してきました。 World Wide Webが1歳になった1992年に最初のWebページを作成しました。さらに、Webアプリケーションを開発しています。

現在、私はロンドンのSpotlightのシステムアーキテクトであり、映画業界のさまざまなプロジェクトに取り組んでいます-非常に興味深い方向です。

私のウェブサイト： dylanbeattie.net そこで、ソフトウェアアーキテクチャ、REST、およびその他の類似のものに関するメモを公開します。また、すべてのスライドのコードがGitHubにあることを言及したいと思います： github.com/dylanbeattie/dotnext/ 。そこからダウンロードして、自分でテストすることができます。

しかし、RESTについて話しましょう。

RESTはかなりよく知られた概念です。多くの人が彼女のことを聞いており、多くの人が彼女と一緒に働いています。ただし、RESTとは何か、この概念が重要である理由、およびRESTを使用して問題を解決する方法については、依然として多くの混乱があります。今日は、これらの質問のいくつかに対する答えを見ていきます。しかし、まず最初に、どのシステムがRESTに対応するのかを明確に考えようとします。したがって、私たちは最初から始めます-ソースに目を向けます。

これがロイ・フィールディングです。ロイはRESTを発明し、それが何であるかを決定しました。すべてがどのように機能するかを説明するソフトウェアおよびコンピューター技術に関する資料が多数あります。使用される単語は、人によって意味が異なります。しかし、RESTには非常に明確な定義があり、これについては最初に説明します。

ロイは現在、アドビのシニアフェローです。それ以前は、Apacheに取り組んでいました。実際、彼はApache Webサーバープロジェクトの創設者の1人であり、World Wide Webをリンクする基本プロトコルであるHTTPの作成者の1人でした。 2000年、Royは論文「ネットワークソフトウェアアーキテクチャのアーキテクチャスタイルと設計」を発表しました。この作品では、Web上のスケーラブルなソフトウェアのアーキテクチャスタイルについて説明しています。

これは理解されるべき最初の瞬間です。 RESTはフレームワークでもライブラリでもありません。単にダウンロードまたはインストールすることはできません。 RESTは、アプリケーションで発生する問題の解決方法に関する一連のルール、制限、推奨事項です。

ロイの論文は非常に人気があります。あなたが根に到達することに興味があるなら、彼らは一見の価値があります。彼の作品では、いくつかの格言を強調したいと思います。

まず、名前を受け取った関連する一連のアーキテクチャ上の制限が、アーキテクチャスタイルになります。彼の意見では、この問題は（建設の文脈で）建築の影響を受け、建築様式についても含め、多くのことを考えました。建物は、設計ではなく、設計ではなく、スタイルで、つまり個々の機能と制限のセットで互いに区別されます。そして、RESTは彼に似ています。これは、システムに適用できるテンプレートのセットです。

また、ソフトウェア開発におけるRESTが何十年も存在していることも非常に重要だと考えています。 すべての細部がソフトウェアの長寿と独立した進化を保証します 。 RESTは、数年、または数十年にわたって機能するシステムを作成するように設計されています。来月までに資金調達が終了すると予想される場合、この概念の下で提示される制限の多くは短期的な有効性と正反対であるため、おそらくREST準拠のシステムを作成すべきではありません。

作業中のプロジェクトでは、問題を解決する方法が2つ以上あることがよくあります。そして、RESTに至るまでの道のりはしばしば長くかかります。このパスでは、あなたとあなたの会社にとって問題にならないかもしれない多くのことを考える必要があります。とても注意してください。まさにあなたが達成しようとしていることを考えてください。長年にわたって機能しなければならないシステムで作業するのに十分幸運である場合、この記事のフレームワークでは、私があなたに役立つことを願う多くのアイデアを見つけるでしょう。

プロトタイプを作成し、何かが機能するかどうかを確認するために多くの実験を行っている場合、状況はあいまいです。 RESTは害を及ぼしませんが、要件によっては速度が低下する場合があります。

REST定義

Roy Fieldingは、RESTの定義を提案しました。これは、調整されたアーキテクチャ上の制約のセットです。

クライアントサーバー

まず第一に、彼によると、ソフトウェアシステムはクライアントとサーバーで動作するように構築する必要があります。これが誰にも驚かないことを願っています。私たちのほとんどは、ウェブサイト、メールシステム、FTPなどのクライアントサーバーアプリケーションを既に作成していると思います。今では非常に一般的です。

詳細は説明しません。サーバーは何らかの方法でクライアント間で分割され、データストレージ、基本機能、およびセキュリティを提供します。これらは一元管理するものです。

顧客の良い点の1つは、それぞれがコンピューターから来ていることです。したがって、実行する必要がある計算がある場合は、それらを多数の顧客に配布できます。したがって、顧客はデータ処理、プレゼンテーション、およびユーザーとの対話を提供します。

サーバーは複数のクライアントにサービスを提供します。そして、これは大きな利点です。もちろん、システムを正しく設計すれば、1台のサーバーを使用して何千人ものユーザーにサービスを提供できます。

状態を保存しない

2番目の制限は、状態の保存の拒否です。 ASP.NET、PHP、ColdFusion、または従来のASPでは、セッションのアイデアを思いつきます。セッションCookieがあります。しかし、この考えはもはや機能しません。 ASP.NETのようなものがあり、1つのWebサーバーを起動すると、少し遅くなり始めました。その後、別のWebサーバーをインストールしましたが、サーバーにリクエストを送信するたびに、このクライアント専用のスペースがストレージに割り当てられたため、すべてが機能しなくなりました。このようなもの：

サーバーはその状態を維持しました。同時に、次の人も入って来ますが、その人にも何らかの病気があります。

サーバーがいっぱいになり、クライアントの1つが離脱するとどうなりますか？彼が戻るかどうかわからないので、しばらくの間その状態を維持しなければなりません。しかし、セッションのタイムアウトはどうあるべきでしょうか？ 5分、10分、24時間？判断するのは非常に困難です。しかし、最大の問題は、さらに多くの機能を提供する別のサーバーを起動し、クライアントの1つが別のサーバーに切り替えようとすると、セッション情報が別の場所に保存されるため、接続が終了することです。

したがって、状態の保存を回避することで、サービスを提供できるクライアントの数とシステムのスケーリング方法に関する柔軟性が高まります。

キャッシング

Royが定義する3番目の制限はキャッシュです。

サーバーに何らかのリソースがあるとします。クライアントが要求します。クライアントが同じリソースを再度必要とする場合、再度要求する必要はありません。彼はすでにそこにあるものを使用できるはずです。

サーバーでタスクを実行すると、リソースが無駄になります。ビデオまたは写真を処理している可能性があります。そして、リソースに見合うだけのものを再利用する必要があります。これが最善です。戻ってきて同じデータを再度要求した人が同じリソースを取得できるように、処理結果を保存する必要があります。

階層化システム

次の制限は、キャッシュの概念に直接関連しています。これは、マルチレベルシステムの考え方です。このアイデアの私のお気に入りの例は、クライアントとサーバー間のキャッシュプロキシです。

この図の顧客は左側にあります。これらは、スマートフォン（iPhone、Samsung、Android）のさまざまなオプションであると想定します。プロキシサーバーはチェーンの途中にあります。大規模な通信会社によって管理されているとしましょう。サーバーの所有者として、プロキシの右側にあるサーバーの作業に対して料金を支払います。結局、クライアントからリクエストが来ると、サーバーはいくつかの計算を実行します。そして、それはお金がかかります-電気、設備の減価償却費など。

通信会社が結果のコピーを保持している場合、誰かが次に情報を要求したときに、プロキシコピーを受け取ります。リクエストの実行にお金をかける必要はありません。したがって、プロキシキャッシングのアイデアは信じられないほど優れています。なぜなら、他の人が追加投資なしでソフトウェアを高速化するために支払うことができるからです。

マルチレベルシステムのアイデアの一部として、中間レベルをさらに追加できます。多層システムでは、サーバーとクライアントはリクエストがどのレベルを通過するかを気にしません。

この例では、クライアントはプロキシサーバーと対話します。プロキシは、サーバーと対話すると考えていますが、実際には、セキュリティレベル（ファイアウォールなど）に要求を送信します。次に、彼はサーバーと通信していると考え、実際にロードバランサーにリクエストを送信します。

ロードバランサーはサーバーと対話すると考えていますが、実際には5台のサーバーについて話しています。新しいものをデプロイし、古いものを閉じることができます。ロードバランサーのおかげで、これは他のレベルに影響しません。

階層型システムの概念により、アプリケーションを計画する際の柔軟性が大幅に向上します。

単一のインターフェース

リソース識別

HTTPおよびRESTが登場する前に、サーバーから情報を取得するには、Gopher、FTP、Telnetなど、数十種類のプロトコルのいずれかを選択する必要がありました。これらはすべて異なるシステムであり、それぞれがリモート情報およびリモートサービスと対話する独自の方法を暗示しています。

HTTPとRESTはこれを標準化しました。まず、リソースの識別が標準化されました-URLが表示されました（誰かがURLを思いついたと思うのは面白いです）。アドレスの一部はプロトコル（HTTP）で定義され、もう一方はリソースへのパス、3番目はポートです。ネットワーク要求にアクセスできるインターネット上のすべてのものは、これらのURLのいずれかを使用して識別できます。

提出操作

表現操作とは、さまざまな形式のデータを要求できることを意味します。データが必要な場合は、CSVテーブル、Excelファイル、テキストドキュメント、jpegとして取得できます。これらはすべて、いくつかの基本的な結果の実際の表現です。

自己記述メッセージ

ネット上で何が起こっているのかを理解できるはずです。 HTTPにはGET、PUT、POST、DELETEリクエストがあります。それらは説明的なものです：GETは、何かを手に入れたいという意味の英語の単語です。 PUTは何かを置くこと、DELETEは削除することを意味します。インテリジェントなデバッグ用のツールでネットワークトラフィックを調べて、実際に送信されたリクエストを把握できます。

アプリケーションの状態を管理するメカニズムとしてのハイパーメディア

これについてさらに詳しく説明します。

エンコードのリクエスト

ロイが確認した最後の制限は、オンデマンドで顧客に提供されるコードを作成するというアイデアです。サーバーがコードを含むデータを送信できる必要があることを意味します。クライアントはこのコードを抽出し、サーバーから切断して、後で起動できます。

これを行うAPIを見たことがない。 Googleドキュメントオフライン、Gmail、その他多くの1ページアプリケーションなど、多くのWebアプリケーションを見てきました。後でシステムで起動するために、他の誰かのAPIから実行可能コードを取得するという考えはサポートしていません。しかし、クライアント上でこのような操作が開始される可能性があることを知ってうれしいです。

電子メールクライアントではない最初のWebブラウザが作成されたときに、私は業界に来ました。その後、誰かがJavaScriptを実行できると判断し、JavaScriptでメールクライアントを作成してクライアントに送信し、ブラウザで実行できるようにしました。

必須の制限

重要なことは、ロイ・フィールディングが率直に言っていることです：6つの制限があり、そのうちの1つだけがオプションです。

説明した方法でシステムを構築して問題を解決すると、システムはRESTfulになります。それらを異なる方法で解決すると、システムはRESTfulになりません。これは、彼女が良いか悪いかを意味するものではありません。上記の定義は、システムの品質については何も言及していません。ただし、定義によってRESTful APIを構成するものについて（元のソースに従って）合意することが非常に重要です。

これらの制限が実際の生活、またはコミックヒーローの生活でどのように見えるかを見てみましょう。 RESTに従って、スーパーヒーロー用のソーシャルネットワークコードを記述してみましょう。楽しいでしょう。

実際のREST

コミック（およびコミック本の映画）の非常に興味深いキャラクターが描かれています。彼らのためにソーシャルネットワークを作成してみましょう。ただし、JavaScriptをテストしたくないのと同じように、ユーザーインターフェイスの開発で行き詰まることは望みません。それでは、APIを作成してみましょう。

エントリーポイントは次のとおりです。

GET / HTTP/1.1

応答として、次のものを取得します。

 200 OK Content-Type: application/json { "message": "Welcome to Herobook!" }

here / profilesというエンドポイントを作成してみましょう。これには2つのメソッドがあります。

 GET /profiles HTTP/1.1

このメソッドは、ソーシャルネットワークに参加したすべてのスーパーヒーローのプロファイルからJavaScript-JSONの配列を返します。

 200 OK Content -Type: application/json [ { "username": "ironman", "name": "Tony Stark", } ]

現時点ではセキュリティについて心配していませんが、この問題は会話の範囲を超えています。

2番目の方法はPOSTです。 /プロファイルにPOSTを送信することにより、ペイロードをJSONとして提供します。

 POST /profiles HTTP/1.1 { "username" : "blackwidow" "name": " ", }

答えは、プロファイルとそのアドレスの作成が成功したことに関するメッセージです。

 201 Created Location: http://api.herobook.local/profiles/blackwidow { "username": "blackwidow", "name": " " }

サービスとそのAPIの説明をインターネット上のどこかに投稿して、誰もがシステムの使用方法を理解できるようにします。

...そして週末は休み。

月曜日に戻ると、サービスに関する情報がネットワーク全体に広がっていることがわかりました。誰かがRedditに載せてTwitterに再投稿し、200万人のユーザーを獲得しました。わあ！

 GET /profiles HTTP/1.1 200 OK { "_links" : { … }, "items" : { { "username":"ironman", "name":"Tony Stark" } { "username":"blackwidow", "name":" " }, { "username":"spidey", "name":"Peter Parker" }, { /* +2 million users! Wow! */ }, { "username":"ducky", "name":"Howard the Duck" } } ]

そして、突然電話が鳴ります。電話を取り、通信の反対側で「APIがチャネル全体をブロックしました！」と言います。そして、別の呼び出し：「あなたのばかげたAPIがデータベースをオーバーロードしています。」

ここで問題は何ですか？どうしたなぜ私たち全員が不幸なのですか？なぜなら、リクエストに応えて200万件のレコードを送信するからです。エンドポイントは1つだけです-/プロファイル。 APIでできることは、データを取得または公開することだけです。そして、これを行おうとすると、毎回200万件のレコードを受け取ります。したがって、誰かがAPIを使用しようとするたびに、メガバイトのデータを受け取ります。ネットワークも、データベースもドロップしています。システム全体はスケーリングしません。

それについて何ができますか？エンドポイントを取得して、分割してみましょう。

 GET /profiles<b>?page=1</b> HTTP/1.1 200 OK { "_links" : { … }, "items" : [ { "username":"ironman", "name":"Tony Stark" } { "username":"spidey", "name":"Peter Parker" }, { "username":"blackwidow", "name": " " }, { "username":"cap", "name":"Steve Rogers" }, { "username":"storm", "name":"Ororo Munroe" } ] }

次に、ページ2をリクエストできます。

 GET /profiles<b>?page=2</b> HTTP/1.1 200 OK

次に3ページ目

 GET /profiles<b>?page=3</b> HTTP/1.1 200 OK

などなど：

 GET /profiles?page=4 HTTP/1.1 200 OK

 GET /profiles?page=5 HTTP/1.1 204 No Content

それは非常にシンプルで、機能します。私たちのほとんどがこれを行うシステムを作成できると確信しています。「コンテンツなし」を取得した場合、すべてのシステムプロファイルがあることを意味します。

ただし、これはRESTではありません。そしてその理由は、APIがアプリケーション状態のエンジンとしてハイパーメディアを使用しないためです。最初のページを取得すると、理論的にはそこからページ2、3に移動できますが、サーバーの応答にはこの可能性を示すものは何もありません。

これで何をしますか？

答えを出す前に、子供の頃の一連の本を思い出します。

これらは、Select Your Adventureシリーズの本です。それらは、8ビットコンピューターでさえも知らないうちに存在していました。最初のページには、ストーリーの一部、そして最後に、次に何をしたいかの選択が表示されます。

例として、状況に合わせて特別なテキストを作成しました。

この「Choose Your Adventure」は、サンクトペテルブルクのドットネクスト専用です。

「サンクトペテルブルクのDotNextで素晴らしい初日を過ごしました。 パーティーの後、会議に参加しています。 忙しい一日でした。 たぶんあなたはあなたの部屋に行って寝るべきですか しかし、寿司を注文する人もいます。 または、パーティーに残り、ユージンがカラオケを歌う様子を見ることができますか？」

このコンテンツは物語の始まりです。そして、結果のプレゼンテーションにハイパーメディア操作が組み込まれています。

「部屋に行って寝るには、23ページに進んでください。

寿司を食べるには、41ページに進み、

パーティーに参加してカラオケを見るには、52ページに進んでください。

これはハイパーメディアです。結果には、システムと対話する方法を説明するハイパーメディアアノテーションが含まれています。

実際にコードでどのように見えるか見てみましょう。これにはhal + json形式を使用します。これは、ハイパーメディアレプリケーション言語用の余分なビットを持つjsonです。この形式を使用する理由は、この形式が非常に短いため、PowerPointスライドに簡単に配置できるためです。

したがって、配列を返すだけでなく、要素のコレクションを作成します。コレクション内のペイロード（コンテンツ）を返すだけでなく、結果を他の場所（ハイパーメディアを通じて実装された利用可能な状態遷移）へのリンクで補完します。

変数インデックスを紹介します-これはあなたがいるページです。合計-コレクション内のエントリの総数。

 GET /profiles HTTP/1.1 200 OK Content -Type: application/hal+json { "_links" : { "self" : { "href" : "http://herobook/profiles?index=0" }, "next" : { "href" : "http://herobook/profiles?index=5" }, "last" : { "href" : "http://herobook/profiles?index=220" } }, "count" :5, "index" :0, "total" : 223, "items:" [ { "username":"ironman", "name":"Tony Stark" } { "username":"spidey", "name":"Peter Parker" }, { "username":"blackwidow", "name":"́ " }, { "username":"pepper", "name":"Pepper Potts" }, { "username":"storm", "name":"Ororo Munroe" } ] }

コードを見てみましょう。

しかし、まず最初に警告したいのは、ここで奇妙なキャラクターに気付くかもしれません。これはC＃です。私はFiraCodeを使用しています。これは次の略です。

あなたが彼らに会うとき、心配しないでください。これらは面白い小さなルーン文字ではなく、数学的な記号です。私はそれらが好きです。 FiraCodeはオープンソースプロジェクトです。こちらからダウンロードできます。

デモンストレーションでは、作成したツールを使用してこのようなことを処理します。 GitHubリポジトリにあります（記事の冒頭のリンク）。

これは、ブラウザー内で実行されるAPI Explorerツールにすぎません。一方では、あなたは素晴らしい仕事ブラウジングをするウェブブラウザを持っていて、AmazonとEbayで物を買う。これらはすべてAPIで非常にうまく機能します。一方、Callcommandlineのようなツール、またはPostmanのような特別なツールがあります。これらは、単一の要求に適しています。ただし、ハイパーメディアシステムをナビゲートする場合は、使用しないでください。私のツールは、これらの両極端のどこかにあります。ブラウザーで動作し（すべてJavaScriptで動作します）、ハイパーメディアを理解します。

APIを使用します。 /プロファイルを入力し、[Go]を押します。

これに応じて、正常に完了したことに関するメッセージ-200 OK-および200万件のレコードを受け取ります（インターネット上で各コミックブックのスーパーヒーローを取り、それらを大きなスプレッドシートに入れたおかげで、私がしなければならなかったのは、このすべてをコピーしてアップロードすることだけでした）。

そのような答えを提供したコードを見てみましょう。

Web API

最初のデモは、asp.net Web APIです。 DotNextでは、ほとんどの人が.NETとASP.NETに精通していると思います。そして、これは単なるWeb APIであり、大したことではありません。

コードは次のとおりです。

ProfilesController（ApiControllerを継承）があります。 DemoDatabase（）データベースと、db.ListProfiles（）を返すパブリックGet（）オブジェクトがあります。

ハイパーメディアの要件に合わせてこのコードをどのように適合させることができますか？結果をページに分割し、あるページから別のページへのリンクを提供します。

最初に行う必要があるのは、配列を何かにラップすることです。データだけを返すことはできません。これに適した.NETの機能の1つは、匿名型を作成する機能です。その後、それらをシリアル化して、それらに入れられたものとほぼ同じものを取得できます。これは本当に強力なツールだと思います。匿名型は、.NETコードモジュール間で渡そうとすると、多くの問題を解決します。ただし、Webサイトを作成するだけであれば、それを直接Jsonに変換してシリアル化し、不要なものを破棄してください。

 public object Get() { var profiles = db.ListProfiles(); var result = new { items = profiles }; return result; }

取得するものは次のとおりです。

まだ200万エントリを出力していますが、配列はJavaScript JSONオブジェクト内にあります。これは、より多くの機能を統合できる場所があることを意味します。

最初にしたいことは、結論を短くすることです。 1ページあたりの結果の数を示す定数を入力するだけです。 10になります。そして、データベースに移動して次のように言います。

  profiles = db.ListProfiles().Take(REULTS_PER_PAGE)

データベースを参照すると、プロファイルは10個しかありません。完全なGet（）コードは次のとおりです。

 <code>public object Get() { var RESULTS_PER_PAGE = 10; var profiles = db.ListProfiles().Take(RESULTS_PER_PAGE) var result = new { items = profiles }; return result; }

ツールに戻り、ページを更新します。 200万の代わりに、10のエントリを取得します（これはスクロールバーで確認できます）。

問題を解決しました。これで、リクエスト/プロファイルがインターネット接続の障害を引き起こすことはなくなります。

次に行うことは、ページをリクエストするためのリンクです。私たちのAPIは適切なページを作成するのに十分スマートです。

ただし、ユーザーはそのような可能性について知らないため、これまでのところ、このシステムはRESTに準拠していません。

コードに戻って何かを修正する必要があります。

匿名型の結果があります。したがって、好きなものをすべて追加できます。特に、リンク。ここでは、C＃文字列補間を使用します。

 var result = new { _links = new { next = new { href = $"/profiles?index={index+RESULTS_PER_PAGE}" } }, items = profiles }; return result;

ここで、プロファイルを要求すると、データ自体だけでなく、リンクのコレクションも取得します。

API Explorerに戻ります。何が起こるか見てみましょう：

したがって、ハイパーメディアをサポートするAPIと呼ばれるものに向けた最初のステップを踏みました。

ページ0があり、ページ間を移動できます。

ただし、APIにはまだいくつかの問題があります。ナビゲーションが必要です。ページを前後に移動でき、リストの最初または最後に移動できる必要があります。 APIはこれをサポートしていませんが。さらに、コレクションの最後に到達すると、システムは空の配列を返し始めます。

APIをRESTの概念と完全に一致させるには、現在のページからどこに行くことができるかを計算するためのロジックを追加する必要があります。

このために、私は小さなヘルパークラスを使用します。

ここで、静的メソッドは動的オブジェクトを返します。彼は何をしていますか？現在のページのインデックス、各ページの要素数、および要素の合計数を指定し、いくつかの計算を実行します-最初と最後のページの番号を取得します。最初のものは常にゼロになり、最後のものには常にコレクション内の最大インデックスを持つプロファイルが含まれます。さらに、インデックスがゼロより大きい場合、戻ることができます。ただし、戻ることはできません。また、index-countが最小インデックスより小さい場合、前進することもできますが、終わりを越えることはできません。

メソッドはリンクを返します。コードに戻り、次のように書き直します。

 public object Get(index = 0) { var RESULTS_PER_PAGE = 10; var profiles = db.ListProfiles() .Skip(index) .Take(RESULTS_PER_PAGE); var total = db.CountProfiles(); var result = new { _links = Hal.Paginate("/profiles", index, RESULTS_PER_PAGE, total), items = profiles }; return result; }

実行してください：

これで、最初、最後、次、前のページへのリンクができました。前進または後退できます。ナビゲーションに使用できるリンクは、最初のページに到達したか最後のページに到達したかを考慮します（最初のページから戻ることはできず、最後から進むことができます）。

したがって、ソーシャルネットワークには200万件の投稿がありました。データを個別のページに分割し、ハイパーメディアを使用して、リソースにアクセスするすべてのユーザーがコレクション内をナビゲートする方法を認識できるようにしました。

リソースの展開

ソーシャルネットワークでは、人々は友人と情報を共有します。彼らは友情を確立し、更新を投稿します。私がいる場所を見てください。」

ネットワークにIron Manがいるとします-Tony Stark。そして彼には友人ハルク、スパイダーマン、ナターシャ・ロマノフがいます。

トニーはステータスを更新します。

 GET /profiles/ironman HTTP/1.1 200 OK Content-Type: application/json { "username": "ironman", "name": "Tony Stark", "friends" : [ { "username":"hulk", "name":"Bruce Banner" }, { "username":"spidey", "name":"Peter Parker" }, { "username":"blackwidow", "name":"́ " }, /* another 500 friends here... */ ] "updates" : [ { "id" : 1234, "update" : "Working a new Iron Man suit!", "posted" : "2016-02-23T18:25:43.511Z"}, { "id" : 1543, "update" : "New suit's gonna have a selfie stick! Oh yeah!", "posted" : "2016-04-16T18:25:43.511Z"}, { "id" : 1782, "update" : "Selfie stick broke. Oh well. Back to the drawing board", "posted" : "2016-04-17T08:26:13.511Z"} ] }

彼の最初の更新：「ねえ、私は新しいアイアンマンのコスチュームを作っています」、次は「エゴイストが素晴らしいので、自撮り棒を乗せます」そして、彼は別のアップデートを公開します。「セルフスティックが壊れました。私は図面に戻り、研究室に戻ります。」

もちろん、彼の友人にもプロフィールがあります。したがって、これらの各更新には友人のリストがあり、これらの各友人には独自の更新があります。

しかし、友人には友人がいて、それらには独自の更新などがあります。

そこで、ビッグデータと呼ばれるものに到達します。

ビッグデータは、このデータのJSONをPowerPointスライドに配置するには大きすぎるためです。それを私の定義にしましょう。

ステータスとその更新のサポートを実装しました。そして、電話が鳴ります：「あなたのAPIはチャネル全体をブロックしました...再び！」、「あなたのAPIはデータベースをオーバーロードしています。繰り返します！..私は、PHPを使用する必要があると言いました...（PHPの以前は、このような問題を聞いたことはなかったでしょう？）

これをどのように修正しますか？この問題を解決するために何をしますか？再びデータを共有します。単一のレコードに関連付けられたグラフ全体を返す代わりに、リンクを提供します。リンクを使用して前後に移動する方法についてはすでに説明しました。次に、このアイデアを拡大します。

 GET /profiles/ironman HTTP/1.1 200 OK Content-Type: application/hal+json { "_links": { "self": { "href" "/profiles/ironman" }, "friends": { "href" : "/profiles/ironman/friends" }, "photos": { "href" : "/profiles/ironman/photos" }, "updates": { "href" : "/profiles/ironman/updates" } }, "username" : "ironman", "name" : "Tony Stark" }

self-表示しているプロファイルを示します。プロファイルを別のルートに残して、すぐに戻ることができるようにしたいためです（これはこのようなシステムの一般的な方法です）。また、友人、写真、アップデートにすばやくアクセスできます-友人、写真、アップデート。

 GET /profiles/ironman HTTP/1.1 200 OK

または

 GET /profiles/ironman/friends HTTP/1.1 200 OK GET /profiles/ironman/updates HTTP/1.1 200 OK GET /profiles/ironman/photos HTTP/1.1 200 OK

写真をリクエストしてみましょう。

 GET /profiles/ironman/photos/1234 HTTP/1.1 200 OK

誰かがこの写真にコメントしました：

 GET /profiles/ironman/photos/1234/comments HTTP/1.1 200 OK

写真1345をリクエストしましょう：

 GET /profiles/ironman/photos/1345 HTTP/1.1 200 OK

そして、ここにも、誰かのコメントがあります：

 GET /profiles/ironman/photos/1345/comments HTTP/1.1 200 OK GET /profiles/ironman/photos/1456 HTTP/1.1 200 OK GET /profiles/ironman/photos/1456/comments HTTP/1.1 200 OK

そして、電話が再び鳴ります：「1ページを与えるためだけに50回API呼び出しを行う必要がありますか?? !!!」。「IISログがC：ドライブをいっぱいにしたため、Webサーバーがクラッシュしました（PHPでこのような問題は一度もありませんでした）」-実際、これはサービスがクラッシュする最も一般的な理由の1つです。

どうする？

私たちは大量のデータを取得し、それが問題を引き起こし、それを共有しました。そして今、小さなデータは他の問題を引き起こします。

いわゆるリソース展開は、これらの問題の解決に役立ちます。 ORMのようなものに精通している場合は、ブートプロセス中に特定のオブジェクトを要求し、そこに別のオブジェクトを含めることができることがわかります。

リソースの展開は、ハイパーメディアAPIの同様のアイデアです。このようにして、Iron Manプロファイルを要求し、その更新を展開できます。

 GET /profiles/ironman?expand=updates HTTP/1.1 200 OK Content-Type: application/json { "_links": { "self" : { "href": "/profiles/ironman" }, "friends" : { "href": "/profiles/ironman/friends" }, "photos" : { "href": "/profiles/ironman/photos" }, "updates" : { "href": "/profiles/ironman/updates" } }, "username" : "ironman", "name" : "Tony Stark" "_embedded" : { "updates" : [ { "update" : "Working a new Iron Man suit – with a built-in selfie stick!", "posted" : "2016-02-23T18:25:43.511Z" }, { "update" : "Selfie stick broke. Oh well. Back to the drawing board", "posted" : "2016-04-17T08:26:13.511Z" } ] } }

繰り返しますが、これを実装する方法を示すコードのデモを行います。 2番目のデモでは、実際に別のサーバー-ナンシーを使用します。

これを行うコードはNancyモジュールです。

アプリケーションのProfileModulesに移動します。ナンシーと一緒に仕事をしたことがない人のために、ここには素晴らしい機能があることに注意してください-GET、PUT、POST、DELETEの各HTTPメソッドの辞書です。

ルートパターンに一致するすべてを含む動的な引数を持つオブジェクトを取得します。次は、呼び出す必要があるメソッドです。

ユーザー名を取得し、db.loadProfileに移動してプロファイルを返します。

ハイパーメディアを追加するために何をしたいですか？ここにリンクの選択を追加します。しかし、db.loadProfileは私たちを引き戻すので、できません。さまざまな企業の理由でリンクを追加することはできません。そのため、データベースを変更せずにリンクを追加します。

Stackoverflowでこれまでに受け取った最もクールなコードを紹介します。 ToDynamicメソッドを呼び出すと、問題が解決します。

 using System.Collections.Generic; using System.ComponentModel; using System.Dynamic; using System.Linq; namespace RealWorldRest.NancyFX.Modules { public static class ObjectExtensions { public static dynamic ToDynamic(this object value) { IDictionary<string, object> expando = new ExpandoObject(); var properties = TypeDescriptor.GetProperties(value.GetType()); foreach (PropertyDescriptor property in properties) { expando.Add(property.Name, property.GetValue(value)); } return (ExpandoObject)expando; } public static IDictionary<string, object> ToDictionary(this object d) { return d.GetType().GetProperties() .ToDictionary(x => x.Name, x => x.GetValue(d, null)); } } }

これは、C＃に組み込まれた拡張メソッドです。彼はオブジェクトを受け取り、反射を使用します。 C＃の基本的な動的型であるExpandableオブジェクトにラップします。次に、リフレクションを使用して、元のオブジェクトのすべてのプロパティを取得します。これらのプロパティごとに、ディクショナリに移動し、プロパティの名前と値を追加します。そして、拡張オブジェクトを返します（動的）。

なぜこれが必要なのですか？データベースから取得したすべてのものを取得し、ToDynamicを呼び出します。現在、これらのオブジェクトは動的であるため開いています。追加のクラスとメソッドを使用できます。これらはすべて実行時に解決されます。自己、写真、アップデートを提供できます。

繰り返しますが、厳密に典型的なC＃企業ソフトウェアの開発に反対側からアプローチし、JSONに変えます。これは、2つの異なるソフトウェアシステムモデリングパラダイムを使用した非常に良い例です。

それで何が得られますか：

これが最初のステップです。これらのハイパーメディアナビゲーションツールを作成しました。アイアンマンの親友を見ることができます。ただし、展開は実装しませんでした。

RESTシステムを作成するプロセスが突然仕様を超えました。 RFC , , . . , . , . . Nancy, , .

( string unnullable, ). : « friends ».

, API Explorer, :

expand=friends, .

, , .NET, C# .. , . JavaScript — , JSON — . .

. , , . .

 GET /profiles/ironman HTTP/1.1 200 OK Content-Type: application/json { "_links": { "self" : { "href": "/profiles/ironman" }, "friends" : { "href": "/profiles/ironman/friends" }, "photos" : { "href": "/profiles/ironman/photos" }, "updates" : { "href": "/profiles/ironman/updates" } }, "name": "Tony Stark", "username": "ironman",

, , . , , . . :

? — ;
? ? ?
?
?
? ?
?
?

, , , , .

 GET /profiles/ironman HTTP/1.1 200 OK Content-Type: application/json { "_links": { "self" : { "href": "/profiles/ironman" }, "friends" : { "href": "/profiles/ironman/friends" }, "photos" : { "href": "/profiles/ironman/photos" }, "updates" : { "href": "/profiles/ironman/updates" } }, "name": "Tony Stark", "username": "ironman", "height": 192, "weight": 85, "location": { "latitude": 59.93, "longitude": 30.33 }, "status": "Out saving the world. Again.", "hometown": "Malibu, USA" "email": "tony@stark.com", "website": "//w.ironman.com", "last_modified" : "2015-08-12T19:45:43.511Z" }

, : « »:

 PUT /profiles/ironman HTTP/1.1 Content-Type: application/json { "name": "Tony Stark", "username": "ironman", "height": 192, "weight": 85, "location": { "lat": 34.02, "lon": -118.77 }, "status" : "Just got back from saving the world. Again.", "hometown": "Malibu, USA" "email": "<a href="mailto:tony@stark.com">tony@stark.com</a>", "website": "//w.ironman.com", "birthdate": "1972-01-24" } 409 Conflict

, , Apple GPS, . , , .

, : PUT , ?

, , . , . — : PUT, , . :

 PUT /profiles/ironman HTTP/1.1 Content-Type: application/json { "status" : "Thinking about a disco Iron Man suit." /*  : JSON     // }

動作します。 , . PUT PUT, .

その結果：

 204 No Content

, , — .

 PUT /profiles/ironman/status HTTP/1.1 "Finished saving the world. I need a drink." 204 No Content

API. . , , , .

— HTTP- PATCH. , .

PATCH , Request URI, , . , «patch document» ( -).

すなわち , PATCH.

? (: «PATCH Method for HTTP» — http://tools.ietf.org/html/rfc5789 ) , . これを実装する方法は？ .

 PATCH /file.txt HTTP/1.1 Host: //w.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100 [description of changes]

. . , PATCH, .

.

Linux. , , patch-, patch.

Content-type (x , ).

, . JSON, «» «», .

 PATCH /profiles/ironman HTTP/1.1 Content-Type: application/x-unix-diff 11c11 < "status": "Just got home from saving the world.", --- > "status": "World saved. I need a drink.", 200 OK

, , , Json-patch. , .

 PATCH /profiles/ironman HTTP/1.1 Content-Type: application/json-patch+json If-Match: "abc123" [ { "op": "replace", "path": "/status", "value": "Finished saving the world. I need a drink." }, { "op": "move", "from": "/friends/hulk", "path": "/friends[0]" } ] 200 OK

, , : , — .

, , — , HTTP-patch.

conferences/dotnext/

 PATCH /conferences/dotnext HTTP/1.1 Content-Type: image/epic.selfie+png

Content-Type — epic.selfie+png. , , — . , . , «202 ». , « », , , DOTNEXT .

, DotNext 2017 Moscow — Life, liberty and the pursuit of APIness: the secret to happy code . , .

, . :

Debugging and Profiling .NET Core Apps on Linux ;
, .NET- ;
- The Metrix has you… .

現実世界のRESTとハイパーメディアの実践