6

現在、内部 REST API を設計しています。次のユースケースがあります。

  1. ユーザー (109) は、別のユーザー (110) に送信したメッセージを読みたいと考えています。
  2. 読み取りユーザー (109) は、認証後に (GET 要求の実行中に) 受け取ったトークン資格情報を通じて、アプリに認識されます。
  3. この例では、ユーザー 109 が送信者であり、110 が受信者であると想定しています。

ユーザー目線でまとめると「私(109)が110に送ったメールをください」

次の URI が思い浮かびましたが、どれを使用するかを決定できません。

a) GET http://localhost:9099/api/mails/109?receiverUserId=110
b) GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110
c) GET http://localhost:9099/api/mails?receiverUserId=110
d) GET http://localhost:9099/api/mails/me/to/110 (when logged in as 109 via token credentials we know that "me" is 109)
f) GET http://localhost:9099/api/mails/109/to/110 (explicit request, e.g. for admins … has to be guarded against illegal access)

すべてのリンクは「コンテキスト依存」であり、リンクの 1 つを受信者 (110) に送信すると、GET 要求を実行してさまざまな結果が得られます。

使用する URL についてご意見をお聞かせください。

どんな助けでも大歓迎です。

乾杯マルセル

4

3 に答える 3

2

同じURLに対して、異なるクライアントへの異なる応答は問題ありません。

StackExchangeはそれを行います：

GET /me/comments/{toid}

これはここに文書化されています。

Twitterもそれを行います：

GET /statuses/home_timeline

これはここに文書化されています。

これらのURLは両方とも、認証に基づいてログインしたユーザーを推測します。はい、ユーザーがキャッシュを共有している場合はキャッシュが無効になりますが、IMO、これは問題ありません。これがRESTの「リソース識別」制約を破るかどうかはおそらく議論の余地があります。この質問への答えとそれに続くコメントは、なぜそれが議論の余地があるのか​​を私に示しています。

実際、オプションの中で、「コンテキスト依存」ではないURLについて言及しています。

GET /api/mails?senderUserId=109&receiverUserId=110

これは常に109から110までのメッセージを返します。ただし、一方のクライアントは「送信済み」メッセージを表示するときにこの結果を表示したいのに対し、もう一方のクライアントは「受信済み」メッセージを表示するときにこの結果を表示したいでしょう。ちょっと変なえ？さらに、サーバーでは、認証されたユーザーが109 | 110であることを確認する必要があります。そうでない場合は、をスローし401 UNAUTHORIZEDます。

私は次のようなもので行きます：

GET /mail/sent

送信されたすべてのメールを返します。と：

GET /mail/sent?to=110 (like applying a 'filter' to /mail/sent)
OR
GET /mail/sent/110 (clean URL)

110に送信されたメールを返します。

于 2012-04-13T09:44:58.067 に答える
1

「コンテキストに依存する」リンクは、REST API には適していません (特に、これはキャッシュを妨げます)。HTTP のみを使用する場合は、これで問題ありません。

そのため、現在のユーザーに依存しない URL を使用し、ルールに従ってアクセスを制限することをお勧めします。

于 2012-04-13T11:29:15.767 に答える
0

私の意見では、2 つのレイヤーが必要です。

1 つは内部レイヤーで、ユーザー認証を必要とせず、内部コンポーネントからのみアクセスできます。次のようなAPIが含まれています

GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110

このレイヤーの利点は、テスト容易性、再利用可能性、およびキャッシュ可能性です。

もう 1 つのレイヤーは外部レイヤーで、ユーザー認証が必要であり、外部クライアントからアクセスできます。次のようなAPIが含まれています

GET http://localhost:9099/api/mails?receiverUserId=110.

クライアントはログインしてトークン資格情報を取得する必要があります。その後、サーバーはこのトークンからユーザー情報を取得し、外部 API 呼び出しを内部 API 呼び出しにマップできます。

さまざまな種類の認証方法を使用できますが、内部レイヤーは変更されません。さまざまな外部レイヤーを内部レイヤーにマップするだけで済みます。

于 2012-04-13T12:44:23.707 に答える