19

HTML5 のサーバー送信イベントが本当に ReST アーキテクチャに適合するかどうか、私には理解できません。HTML5/HTTP のすべての側面が ReST アーキテクチャに適合する必要があるわけではないことを理解しています。しかし、私は専門家から、HTTP のどちらの半分が SSE であるか (ReSTful の半分または残りの半分!) を知りたいと思います。

クライアントからサーバーへの「最初の」HTTP GET 要求があり、残りは単に異なる Content-type ("text/event-ストリーム"）

response(events) として返される応答の数を知らずに送信された要求? それはReSTfulですか？

質問の動機: 私たちはアプリのサーバー側を開発しており、ReST クライアント (一般) とブラウザー (特に) の両方をサポートしたいと考えています。SSE はほとんどの HTML5 ブラウザー クライアントで機能しますが、SSE が純粋な ReST クライアントによるサポートに適しているかどうかはわかりません。したがって、質問です。

Edit1 : Roy Fielding の古い記事を読んでいて、彼は次のように述べています。インターネットでは、善意のユーザーのためだけに設計する余裕はないため、HTTP システムでは、このようなリクエストをサービス拒否エクスプロイトと呼びます..これがまさに、標準的なメカニズムがない理由です。 HTTP での通知用"

それは SSE が ReSTful ではないことを意味しますか?

Edit2 : Twitter の REST API を使用していました。REST ピューリタンは、REST API が本当に/完全に REST であるかどうかについて議論するかもしれませんが、ストリーミングと REST の違いのセクションのタイトルだけで、ストリーミング (および SSE でさえも) は ReSTful と見なすことはできない!? 誰もそれを主張しますか？

4

2 に答える 2

4

私はそれが依存すると思います：

サーバー側のイベントでは、ハイパーメディアやハイパーリンクを使用して状態変化の可能性を説明していますか?

その質問に対する答えは、アプリケーション アーキテクチャ内で REST を満たすかどうかの答えです。

現在、これらのイベントが送受信される方法は、REST に準拠している場合と準拠していない場合があります。SSE について私が読んだすべてのことは、REST が準拠していないことを示唆しています。いくつかの原則、特に階層化に影響を与えると思いますが、仲介者が SSE のセマンティクスを認識していれば、おそらくこれを否定できるでしょう。

これは、ブラウザーが (実行中の JavaScript を介して) 理解する HTML および JavaScript の処理ディレクティブの一部にすぎないため、直交していると思います。クライアント側のアプリケーションの状態をサーバー側のリソースの状態から切り離すことができるはずです。

SSE を使用してスケーリングを処理する方法について私が見たアドバイスのいくつかは、REST には適合しません。つまり、カスタム ヘッダーの導入 (プロトコルの変更) です。

SSE を使用しているときに REST をどのように尊重しますか?

私はいくつかの種類を見たいです

<link rel="event" href="http://example.com/user/1" />

次に、作業しているコンテンツ タイプ/リソースの処理ディレクティブ (JavaScript などのコード オン デマンドを含む) は、そのようなハイパーリンクから利用できるイベントをサブスクライブして利用する方法をクライアントに伝えます。明らかに、これらのイベントのデータ自体は、プログラム フローを制御するハイパーリンクをさらに含むハイパーメディアである必要があります。(ここで、REST と非 REST を区別していると思います)。

ある時点で、ブラウザはそのリンク関係を認識することができます - と同じように、stylesheetその手の込んだ接続をいくつか行うため、JavaScript でイベントをリッスンするだけです。

あなたのアプリケーションは SSE の周りの REST スタイルにまだ適合できると思いますが、それらは REST そのものではありません (あなたの質問は具体的にはそれらの使用に関するものであり、実装に関するものではないので、私が話していることを明確にしようとしています)。

仕様が HTTP を使用するのは好きではありません。なぜなら、多くのセマンティクスが取り除かれ、貧弱なプロトコルが比較的豊富なプロトコルを介して効果的にトンネリングされるからです。これはおそらく利点ですが、昼食代を支払うために夕食を売っているような気がします。

ReST clients (in general) and Browsers (in particular).

ブラウザが REST クライアントでないのはなぜですか? ブラウザーは、間違いなく最も多くの REST クライアントです。JavaScript を介してそれらに固執するのは、すべてがらくたであり、REST に固執するのをやめさせます。私は、REST-API の「クライアント」とブラウザー クライアントが根本的に異なるものであると考え続ける限り、現在の状態にとどまるのではないかと疑っています/恐れています。 RPC の人々は、存在する必要があるとは考えていません ;)

于 2013-06-05T18:52:00.093 に答える