web-dev-qa-db-ja.com

RESTサーバーとRESTクライアントの違い

RESTチュートリアルを含む)に関する記事を読んでいます。このサイトを見たことがある http://www.vogella.com/tutorials/REST/article.html 、残りを次のように説明する部分があります:

RESTベースのアーキテクチャでは、RESTサーバーがリソースへのアクセスを提供します。ARESTクライアントはアクセスできますRESTリソースを変更します。

REST server and REST clientの意味を検索しましたが、良い答えを見つけることができませんでした。誰かがそれらを説明できますか?

3
grapes berry

サーバーはAPIを公開し、クライアントはそれを利用します。

たとえば、Twitterには共有したいデータ(とりわけ、Tweets)があるため、RESTサーバー(複数の可能性があります))によって提供されるAPIを公開します。そのAPIを使用してツイートを取得してユーザーに公開するモバイルアプリの場合、モバイルアプリはRESTクライアントになります。

9
Paul

それを考える最も簡単な方法はこれです:

  • サーバー応答要求に
  • クライアント作るリクエスト

サーバーとクライアントについて話すとき、それは常にあなたが現在話し合っているコードに関連しています。 Webサーバーが要求に応答するコードは、常にサーバー部分です。 Webサーバーに接続するコードは常にクライアントです。

6
Berin Loritsch

@Paulと@Berinの回答に加えて、これらは非常に正確で簡潔です。

REST server and REST clientの意味を検索しましたが、良い答えを見つけることができませんでした。誰かがそれらを説明できますか?

短い答えは

少し長い答えは

  • RESTfulサーバー(アプリケーション)は、提供を使用して[リソースおよびこれらのリソースの管理を実行できるアプリケーションです[〜#〜] www [〜#〜][〜#〜] http [〜#〜] 仕様を通信プロトコルとして採用。

  • RESTfulクライアント(アプリケーション)は、消費およびリソースで操作 RESTfulサーバーによって公開されるアプリケーション同じ前提の下に対応したアプリケーションです。

素人の言葉で、

  • RESTfulアプリケーションとは、WWWアーキテクチャの機能を完全に取り入れたアプリケーションです

Leonard Richardson とSamy Rubyは、これらすべての前提と制約を包含するアーキテクチャスタイルを考案しました。 Resource Oriented Architecture )。RESTアプリケーション(APIおよびサービス))の解釈はコミュニティによって広く採用されており、このトピックに関する本、ブログ、および記事の急増を促進しています。それらのすべて、フィールディング論文。


RESTful実装の相違

RESTfulアプリケーションの乱暴な市場では、Fieldingの制約を完全に満たしていないというのが真実であるときに、アプリケーションがRESTfulであると主張するのを目にするでしょう。1

RESTのすべてのアーキテクチャ上の制約を達成することはトレードオフの免除ではありません。コミュニティはこれらの制約を実装する際にある程度の柔軟性を採用する必要がありました。いつものように、それは適合性の問題であり、費用対効果。

制約の中では、niformインターフェースが他より際立っています。 HTTPセマンティクスとコンテンツrepresentingに私たちのビジネス(サービス、モデルなど)をRESTfulな方法で採用させるので、この制約は特に関連があります。2

RESTの各実装は、プロジェクト間およびプロバイダー間で著しく異なります。それぞれが異なる要件、ニーズ、およびリソースを処理する必要があるため、理解できます。最終的に、要件とニーズが優先されます残り。


1:RESTfulでないことを意味しますか?まあ、それは議論や意見に開放されています。どちらもトピックから外れています。

2:その関連性の例は、 [〜#〜] se [〜#〜] および [〜#〜] so [〜#に含まれる多数の記事、ガイド、または質問です。 〜]RIs 、Httpメソッド、Httpステータスなどを正常に実装する方法について。ビジネスの期待に首尾よく応えるため。

2
Laiv

REST server and REST clientの意味を検索しましたが、良い答えを見つけることができませんでした。誰かがそれらを説明できますか?

疑問がある場合は、ソースにアクセスしてください: Fieldingの論文 ここで、彼はREST建築スタイルを定義しています。

第5章 で、彼は最初の制約としてクライアントサーバーを説明しています。

懸念の分離は、クライアント/サーバー制約の背後にある原則です。ユーザーインターフェイスの問題をデータストレージの問題から分離することにより、複数のプラットフォームにわたるユーザーインターフェイスの移植性を向上させ、サーバーコンポーネントを簡略化することでスケーラビリティを改善します。ただし、おそらくWebで最も重要なのは、分離によってコンポーネントが独立して進化できるため、複数の組織ドメインのインターネット規模の要件をサポートできることです。

Client-Serverアーキテクチャスタイルの説明は Chapter にあり、Fieldingの属性は Gregory Andrews に属しています。

クライアントはトリガープロセスです。サーバーは反応的なプロセスです。クライアントは、サーバーからの反応をトリガーする要求を行います。したがって、クライアントは選択時にアクティビティを開始します。その後、リクエストが処理されるまで遅延することがよくあります。一方、サーバーは要求が行われるのを待ってから、要求に応答します。サーバーは通常、非終了プロセスであり、多くの場合、複数のクライアントにサービスを提供します。

つまり、REST clientとa REST server is both connectors

2つの基本的な違いは、クライアントがリクエストを行うことで通信を開始するのに対し、サーバーは接続をリッスンし、リクエストに応答してサービスへのアクセスを提供することです。コンポーネントには、クライアントコネクタとサーバーコネクタの両方を含めることができます。

フィールディングは、ここでの彼の定義において多少正確であることに注意してください。彼は components という用語を使用して、果たす役割を説明しています。

ユーザーエージェントは、クライアントコネクタを使用して要求を開始し、応答の最終的な受信者になります。最も一般的な例はWebブラウザです...

オリジンサーバーはサーバーコネクターを使用して、要求されたリソースの名前空間を管理します。これは、そのリソースの表現の決定的なソースであり、そのリソースの値を変更しようとするあらゆる要求の最終的な受信者でなければなりません。

中間コンポーネントは、クライアントとサーバーの両方として機能します。

一般的な談話では、REST clientはユーザーエージェントコンポーネントを意味し、REST serverはOriginサーバーコンポーネントを意味します。

1
VoiceOfUnreason