RESTとHATEOASはWebサービスに適したアーキテクチャですか？

正しく理解できれば、RESTはWebのアーキテクチャの記述モデルとしてRoy Fieldingによって正式化されました。AFAIK FieldingはRESTが良いと主張したわけではなく、Webの事実上のアーキテクチャを説明しているだけでした。Webはこの時点ですでに非常に成功した分散ハイパーテキストシステムを証明しているため、この種のRESTは、主に人間がナビゲートして消費する分散ハイパーメディアのドメインの成功したアーキテクチャとして検証されます。

REST Webサービスは、RESTアーキテクチャをAPIに適用することで作成されました。しかし、実際にはRESTがこのドメインに望ましいアーキテクチャであると考える理由はありますか？より具体的には、HATEOASがマシンツーマシン通信の有益な設計原則であるという証拠はありますか？

私の懸念は、よく知られているコンテンツタイプ（HTML、画像、ビデオなど）がほとんどなく、クライアントがそれらを使用する方法を知っているため、HATEOASはハイパーメディアに意味があることです。ただし、APIの場合、コンテンツタイプは非常に具体的であり、クライアントがそれらを消費するように特別にプログラムされている場合にのみ、クライアントが意味のある方法で消費できます。クライアントにURLを返すだけでは、クライアントは指定されたリソースを消費できません。

AFAIK FieldingはRESTが良いと主張したわけではなく、Webの事実上のアーキテクチャを説明しているだけでした。

それが少し強調されていると思います。結局のところ、RESTはフィールディングがHTTP / 1.1仕様のチーフアーキテクトとして使用していたアーキテクチャスタイルの列挙です。

しかし、実際にはRESTがこのドメインに望ましいアーキテクチャであると考える理由はありますか？HATEOASがマシンツーマシン通信の有益な設計原則であるという証拠はありますか？

"場合によります"。HATEOASはRESTの統一されたインターフェイス制約の一部です。

一般的なソフトウェアエンジニアリングの原則をコンポーネントインターフェイスに適用することにより、システムアーキテクチャ全体が簡素化され、相互作用の可視性が向上します。実装は、提供するサービスから切り離されているため、独立した進化が促進されます。ただし、情報はアプリケーションのニーズに固有の形式ではなく、標準化された形式で転送されるため、均一なインターフェイスでは効率が低下します。RESTインターフェースは、大規模なハイパーメディアデータ転送に効率的で、Webの一般的なケースを最適化するように設計されていますが、他の形式のアーキテクチャの相互作用には最適ではないインターフェースになります。

それでは、これが何を意味するかについて少し考えてみましょう。ワイヤレスルーターで問題が発生した場合、stackexchangeに回答を送信するために使用するのと同じブラウザーを使用して、ワイヤレスルーターと通信できます。特に、どのブラウザを使用しているか、またはブラウザが期待しているものより遅れている（または進んでいる）更新があるかどうかは関係ありません。ブラウザを作成したエンジニアリング組織が、ルーターインターフェイスを作成した組織から完全に独立していることは問題ではありません。

それ だけで動作します。

もちろん、普遍的ではありません。 フィールディング、2008年に次のように書きました。

だからといって、誰もがRESTアーキテクチャスタイルに従って独自のシステムを設計するべきだと思うわけではありません。RESTは、複数の組織にまたがる長寿命のネットワークベースのアプリケーションを対象としています。制約が必要でない場合は、使用しないでください。

RESTアーキテクチャスタイルを形成する制約は、それらが引き起こすプロパティに対して選択されました。これらのプロパティがユースケースにとって価値がない場合、対応する制約の削除を絶対に検討する必要があります。

マシンツーマシンが難しくなるのは、人間が表現によって提供されるセマンティクスとあいまいに一致する能力を失ったことです。クライアントはメディアタイプだけを知っていればうまくいきますが、通常、意味を引き出すためのセマンティックキューを見ている人間がいます。

schema.orgは、機械可読な語彙を作成する取り組みの一部です。マシンエージェントはクライアントを使用してセマンティックヒントを見つけ、その意味の独自の理解を適用して、実行する正しいアクションを選択します。

しかし、それは仕事です。リソースのマシンフレンドリーな表現の開発に投資する必要があり、それらの表現が上位および下位互換性を維持し、クライアントが独立して開発できるようにする必要があります。

単一の組織がクライアントとサーバーの両方を制御する場合、この独立性の利点ははるかに小さく、その場合、制約は適切なアーキテクチャの選択ではない可能性があります。

いいえ、「フルREST」はそれほど素晴らしいものではありません。

これらのAPIにHATEOSを実装する人々の不足と、特定の呼び出しに使用するHTTP動詞に関する無限の議論から明らかです。

しかし、RESTが非常に人気がある理由を認識する必要があります。採用される前は、確認、タイムアウト、会話ID、および状態を含むebXMLやSOAPなど、さまざまな複雑なプロトコルがありました。

これらのことを実行してから説明する、APIの利用者にするのは大変な作業でした。「クエリ文字列に必要なIDを指定してGETを実行して、データを送信しないのはなぜですか？」明白で一般的な質問でした。

次に、2番目の問題はXMLで、javascriptはそれを理解しませんでした。スキーマはお尻を痛め、ほとんどがで構成される巨大なtxtファイルになります<MyLongObjectName>。そこで人々は代わりにJSONを使い始めました。

現在、RESTにはちょっとしたカルトがありますが、ルールが曖昧なので、消費者が6か月間搭乗せずに「簡単に入手」して使用できるほど簡単な使用可能なAPIをノックアップすることを妨げません処理する。

RoyはRESTの原則のほとんどの最初の発明者ではなく、以前のシステムでさまざまな特定の問題を解決するために機能することが知られている多くの原則をまとめていることに注意してください。RESTは、これらの原則を単一のアーキテクチャに適用するという自然な結論にすぎません。

Roy FieldingがRESTに関する論文を書く前でも、HTTPはすでにRESTとして知られるようになった原則に基づいて既に設計されていました。彼の論文の結論では、彼は書いた：

既存のHypertext Transfer Protocol（HTTP / 1.0）[19]を定義し、HTTP / 1.1 [42]およびUniform Resource Identifiers（URI）[21]の新しい標準の拡張を設計するインターネットエンジニアリングタスクフォース内の取り組みの開始時に]、World Wide Webの動作モデルの必要性を認識しました。Representational State Transfer（REST）アーキテクチャスタイルと呼ばれるWebアプリケーション全体の相互作用のこの理想化されたモデルは、既存のアーキテクチャの欠陥を特定し、拡張することができる指針となる、現代のWebアーキテクチャの基盤となりました。展開前に検証済み。

RESTおよびHATEOSは、次の目的で設計された問題に最適です。

RESTは、コンポーネントの実装の独立性とスケーラビリティを同時に最大化しながら、レイテンシとネットワーク通信を最小化しようとする、一連のアーキテクチャ上の制約です。これは、他のスタイルがコンポーネントのセマンティクスに焦点を合わせている場合に、コネクターのセマンティクスに制約を設定することにより実現されます。RESTを使用すると、相互作用のキャッシュと再利用、コンポーネントの動的な代替、および仲介者によるアクションの処理が可能になり、インターネット規模の分散ハイパーメディアシステムのニーズを満たすことができます。

ただし、WebとRESTは必ずしもすべての問題に適しているわけではないことに注意してください。

同様に、提案された拡張機能をRESTと比較して、アーキテクチャに適合するかどうかを確認できます。そうでない場合は、その機能を、より適切なアーキテクチャスタイルと並行して実行されているシステムにリダイレクトする方が効率的です。

あなたの質問が「RESTとHATEOASはWebサービスに適したアーキテクチャですか？」その場合、答えは「はい、Webサービスに適したアーキテクチャです」です。問題は、人々がWebの制約に後付けすることで解決しようとしたすべての問題が、実際にWebサービスだったのかどうかです。

本当にRESTに適合しないAPIがたくさんあります。RESTが解決するように設計された種類のスケーラビリティを必要としないAPIは、独立して進化する可能性のある複数の組織によって消費されることはなく、長期間存続する必要もありません。これらの問題については、REST制約は単なる拘束です。

しかし、実際にはRESTがこのドメインに望ましいアーキテクチャであると考える理由はありますか？より具体的には、HATEOASはマシンツーマシン通信の有益な設計原則であるという証拠はありますか？

証拠は、多くの人々の問題を解決するウェブの成功です。RESTは、以前の多くのアーキテクチャスタイルの設計を組み合わせたハイブリッドアーキテクチャです。多くの問題ドメインはWebのすべての要件を備えているわけではなく、RESTのすべての制約に従う必要はありません。これが、RESTの一部を適用するだけで正常に機能する多くの成功したアーキテクチャがあり、その他の部分はない理由です。たとえば、HATEOASおよびUniform Interfaceは、廃止予定期間が比較的短い組織の境界やシステムを越える必要がないAPIによってしばしばスキップされる原則です。

Adobe Experience Managerに関するFieldingのプレゼンテーション：

RESTはアーキテクチャではありません！

レストは、インターネット上に存在するさまざまなアーキテクチャを抽象化したアーキテクチャスタイルです。

RESTは、建築特性を誘導するための設計制約の蓄積です

RESTは流行語であり、誰もがRESTful APIを望んでいます。現実には、REST制約に直面したとき、すべての制約を適用する必要性や利益を得る必要がないため、これらの制約の一部を削除しました。

すでに述べたように、HATEOASは、クライアントがWebブラウザーの場合に役立ちます。クライアントがモバイルアプリの場合、それほど多くはありません。それは良い習慣ですが、そのようなアプリケーションの設計にはコストがかかるため、例を挙げると、モバイルアプリチームとバックエンドチームがその制約をやめることに同意しただけです。そして、両方のチームが同じ会社で働いているので、両方のチームがそれほど疎結合ではないので、その種の意味があります。

AEMのREST

他のサーバーが使用するサービスを作成する場合は、xmlrpcが正しい選択です。あなたが望むのが、シンクライアントや低電力デバイス、またはオープンインターネット上の未知のクライアントによって消費されるサービスであるなら、おそらくjsonを使用した残りを検討してください。ただし、jsonはxmlと比較した場合、一般データを指定するための劣った表記法であることを忘れないでください。