0

リソース /users とリソース /claims がある場合、/claims/7 は次を返します。

{ id: 7, text: "hello", postingUserID: 9 }

それは大丈夫ですか？それともそうあるべきか

{ id: 7, text: "hello", postingUserURI: "/users/9" }

後者の方が落ち着いていると思いますが、ID で何か他のことをしたい場合は 9 を解析しなければならないので不便です。

それとも両方持っているべきでしょうか？

{ id: 7, text: "hello", postingUserID: 9, postingUserURI: "/users/9" }

私はこれが好きですが、少し冗長でもあります。

一番落ち着くのは何ですか？ありがとう！

4

1 に答える 1

1

最も RESTful なことは、URI を含めることです。最初のオプションは行き止まりを表しているため、RESTful クライアントにはあまり役に立ちません。Web ブラウザーは、安らかなクライアントの好例です。オプション 1 は、ハイパーリンクのない Web ページを提供するようなものです。ユーザーはアプリケーションの状態 (ブラウザー タブ) を進める手段がなく、ページを読んでから [戻る] ボタンを押すことしかできません。

オプション 2 をお勧めします。ID は、URI テンプレートを使用して生成された RPC スタイルの HTTP 要求などにしか使用できないため、クライアントは ID を必要としません。これは、REST ではないアウトオブバンド情報を表します。ID は、公開する必要のない内部実装の詳細です。クレーム オブジェクトの ID を含める必要さえありません。クライアントで現在 ID を使用しているものはすべて、前の要求から受け取ったハイパーリンクを使用する必要があります。

例として、私自身の API には「ジョブ番号」があります。この番号は、アルファベット部分のない整数です。データベースの自動インクリメント ID フィールドを使用して、これらのジョブ番号を生成して保存しますが、クライアントに提示するときは、データベース ID ではなく「ジョブ番号」として提示します。クライアントは、将来のリクエストを生成するためにこれを使用せず、人間が読める表示のためにのみ使用します。

新しい API を開発する場合、JSON 応答のような HTML ページを出力すると便利な場合があります。次に、Web ブラウザーを使用してその中を移動します。すべての GET 要求は、URL バーに ID を入力するのではなく、ハイパーリンク (アンカー要素) をクリックして生成する必要があります。この手法は、API Surfing として知られています。

REST とは関係ありませんが、URI のフィールド名として に変更postingUserURIします。author

于 2013-01-09T09:10:16.170 に答える