ウィキペディアでいくつかの参照リンクを含む適切な説明を見つけましたが、より良い説明があるかもしれません。これらを見つけるのを手伝ってください!
明確にするために、私は言語固有の実装ガイドの実装を探しているのではなく、純粋な概念だけを探しています。
ウィキペディアでいくつかの参照リンクを含む適切な説明を見つけましたが、より良い説明があるかもしれません。これらを見つけるのを手伝ってください!
明確にするために、私は言語固有の実装ガイドの実装を探しているのではなく、純粋な概念だけを探しています。
RESTful Web サービスを構築するためのガイドラインには、必要なリソースに関するすべての情報が含まれています。
これは、もう 1 つの便利なブログ エントリです。
統一されたインターフェイスの制約は、Web 用に構築されたサービスが Web アーキテクチャの適切な参加者になる方法を説明しています。これらの制約は、次のように簡単に説明されています。
1) リソースの識別: リソースとは、名前を付けて表すことができる任意の情報項目です (たとえば、ドキュメント、特定の時点での株価、ラスベガスの現在の天気など)。サービス内のリソースは、URI を使用して識別する必要があります。
2) 表現によるリソースの操作: 表現は、リソースの物理的な表現であり、有効なメディア タイプに対応する必要があります。サービスの背後にあるデータ形式として標準のメディア タイプを使用すると、幅広い潜在的なクライアントがサービスにアクセスできるようになり、サービスの範囲が広がります。リソースとの相互作用は、その URI によって識別されるリソースの表現の取得と操作に基づく必要があります。
3) 自己記述型メッセージ: サービスのインタラクションでステートレスの原則に従い、標準のメディア タイプを使用し、HTTP メソッドの使用法と制御ヘッダーを介してメッセージのキャッシュ可能性を正しく示すことで、メッセージが自己記述的であることを保証します。自己記述型メッセージにより、クライアントとサーバーのどちらにも影響を与えずにメッセージを仲介者が処理できるようになります。
4) アプリケーション状態のエンジンとしてのハイパーメディア: アプリケーション状態は、URI とハイパーリンクを使用して表現し、状態間の遷移を行う必要があります。これはおそらく、 Roy Fielding の論文で説明されているアーキテクチャ上の制約の中で最も物議を醸し、最も理解されていないものです。実際、フィールディングの論文には、アプリケーションの状態を表すために HTTP Cookie を使用することに反対する明確な議論が含まれており、この点を強調していますが、しばしば無視されています。
または、馬の口から直接取得することもできます。アーキテクチャ スタイルとネットワーク ベースのソフトウェア アーキテクチャの設計
O'Reilly の RESTful Web サービスを読んで、本当に楽しかったです。
あなたが探している詳細がどれくらいかはわかりませんが、REST とは何かについての幅広い概要については、Ryan Tomayko のHow I Explained REST to My Wifeをお勧めします。