9

Webアプリケーションは、過去数年間で大きなパラダイムシフトを経験しました。

10年前（そして残念ながら今日でも）、Webアプリケーションは重量のあるサーバーにのみ存在し、データからプレゼンテーション形式まですべてを処理し、サーバーの出力のみをレンダリングするダムクライアント（ブラウザー）に送信していました。

その後、AJAXがゲームに参加し、Webアプリケーションがサーバーとブラウザーの間に存在するものに変わり始めました。

AJAXのクライマックスの間、Webアプリケーションロジックは完全にブラウザ上で動作し始めました。これは、HTTPRESTfulAPIが登場し始めたときだったと思います。突然、すべての新しいサービスにその種のRESTful APIが追加され、突然JavaScriptMV*フレームワークがポップコーンのように飛び出し始めました。モバイルデバイスの使用も大幅に増加し、RESTはこの種のシナリオに最適です。ここでは「一種のRESTful」と言います。これは、RESTであると主張するほとんどすべてのAPIがそうではないためです。しかし、それはまったく別の話です。

実際、私は一種の「RESTエバンジェリスト」になりました。

Webアプリケーションはこれ以上進化できないと思ったとき、新しい時代が幕を開けたようです。ステートフルな持続的接続Webアプリケーションです。 Meteorは、その種のアプリケーションの優れたフレームワークの例です。それから私はこのビデオを見ました。このビデオでは、マット・デバーガリスがメテオについて語っています。どちらも素晴らしい仕事をしています。ただし、彼はこの種の目的でREST APIを停止し、永続的なリアルタイム接続を優先しています。

たとえば、リアルタイムのモデル更新が欲しいのですが、それでもすべてのRESTの素晴らしさを持っています。 ストリーミングRESTAPIは私が必要としているもののようです（たとえば、firehose.ioやTwitterのAPI）が、この新しい種類のAPIに関する情報はほとんどありません。

だから私の質問は：

Webベースのリアルタイム通信はRESTパラダイムと互換性がありませんか？

（長い紹介文で申し訳ありませんが、この質問はいくつかの文脈でのみ意味があると思いました）

4

3 に答える 3

3

移動しない限り、Web アプリケーションのステートフルで永続的な tcp/ip 接続は優れています。

私はリアルタイム Web ベースのフレームワークを開発しましたが、私の経験では、モバイル デバイス ベースの Web ブラウザーを使用すると、タワーからタワーへ、または Wi-Fi から Wi-Fi に移動すると、IP アドレスが変化し続けることがわかりました。

IP アドレスが変化し続けると、それが永続的な接続であるという概念はすぐに消え去ります。

リアルタイム Web アプリのフレームワークは、接続が一時的であり、バックエンドへの基礎となる IP 接続が変化し続ける間、フレームワークがセッションの独自の概念を実装する必要があるという前提で設計する必要があります。

セッションが定義され、クライアントとサーバー間のすべての要求と応答で使用されると、基本的に「Web 接続」が確立されます。そして今、REST パラダイムを使用して、リアルタイムの Web ベースのアプリを開発できます。

フレームワークのバックエンド サーバーは、IP アドレスの移行中に更新をキューに入れ、tcp/ip 接続が再確立されたときに同期するようにインテリジェントである必要があります。

簡単に言えば、「はい、REST パラダイムを使用してリアルタイムの Web ベースのアプリを作成できます」です。

一緒にプレイしたい場合は、お知らせください。

于 2012-12-17T19:57:10.603 に答える
2

私もこのテーマに非常に興味があります。この投稿には、不適切な設計の RPC に伴ういくつかの問題について説明している論文へのリンクがいくつかあります。

http://thomasdavis.github.com/2012/04/11/the-obligatory-refutation-of-rpc.html

私は Meteor についてあまり知らないので、Meteor の設計が不十分だと言っているわけではありません。

いずれにせよ、両方の「世界」のベストを尽くしたいと思っています。REST と、制約のある汎用インターフェース、アドレス可能性、ステートレス性などで提供されるすべての利点を活用したいと考えています。

そして、この「リアルタイム」の Web 革命にも取り残されたくありません。それは間違いなく非常に素晴らしいです。

機能するハイブリッドアプローチがないかどうか疑問に思っています:

RESTful エンドポイントを使用すると、クライアントはスペースに入り、HATEOAS が要求する関連ドキュメントへのリンクをたどることができます。しかし、リソースへの「更新のストリーム」の場合、おそらく「サブスクリプション名」自体が URI である可能性があり、Web ブラウザーのアドレス バーや curl などを介して、特定の時点の単一の要求で参照すると、 「現在の状態」の表現、またはリソースの以前の状態の href を含むリンクのリスト、および/またはオブジェクトに対して発生した個別の「イベント」を照会する方法のいずれかを返します。

このように、エンティティの「バージョン 1」で状態を示し、それに対して各イベントを再生すると、エンティティを「現在の状態」に変更することができ、このイベントはクライアントにストリーミングできます。エンティティの 1 つの小さな部分が変更されたという理由だけで、完全な表現を取得したくありません。これは基本的に「イベント ストア」の概念であり、多くの CQRS 情報でカバーされています。

REST と互換性がある限り、このアプローチは既に行われていると思います (ただし、ストリーミング側についてはよくわかりません)。/9780596805838.do (REST in Practice)、または QCon 2010 の録画された講演で Vaughn Vernon が聞いたプレゼンテーション: http://www.infoq.com/presentations/RESTful-SOA-DDD。

彼はこのような URI 設計について話しました (正確には覚えていません)。

host/entity <-- リソースの現在のバージョン host/entity/events <-- オブジェクトを現在の状態に変更するために発生したイベントのリスト

例：

host/entity/events/1 <-- これはエンティティの作成に対応します host/entity/events/2 <-- これはエンティティに対する 2 番目のイベントに対応します

彼はまた、歴史のために何かを持っていたかもしれません。完全な瞬間の状態です。

host/entity/version/2 <-- これは、上記のイベント 2 後のエンティティの全体的な状態になります。

Vaughn は最近、本、Implementing Domain-Driven Design を出版しました。目次から見ると、REST とイベント駆動型アーキテクチャをカバーしているように見えます: http://www.amazon.com/gp/product/0321834577

于 2013-02-02T04:46:19.280 に答える
0

私はhttp://firehose.io/の作成者です。これは、ストリーミング RESTful API が存在できる、また存在すべきであるという前提に基づくリアルタイム フレームワークです。プロジェクトのウェブサイトから：

Firehose は、複雑なプロトコルを使用したり、アプリをゼロから書き直したりすることなく、リアルタイム Web アプリを構築する侵襲性を最小限に抑えた方法です。WebSockets または HTTP ロング ポーリングを介してクライアント側の Javascript モデルをサーバー コードと同期させる、ダート シンプルな pub/sub サーバーです。RESTful な設計パターンを完全に取り入れているため、アプリを構築した後は優れた API が得られます。

このフレームワークがインターネットが RPC の暗黒時代に逆戻りするのを防いでくれることを願っていますが、どうなるか見ていきます。Poll Everywhereでは Firehose.io を本番環境で使用して、1 日あたり何百万ものメッセージをあらゆる種類のデバイスの人々にプッシュしています。できます。

于 2013-09-11T04:46:02.707 に答える