1
  • /users/{username}が (一方が他方なしでは存在できない)のエイリアスである場合/users/{userId}、前者を削除することは後者を削除することを意味すると予想しています。
  • へ/lists/{listId}/users/{userId}の参照である場合/users/{userId}（一方が他方なしで存在できる）、正規リソースに影響を与えることなく参照を削除できると期待しています。
  • どちらの場合も、呼び出すと正規リソースへのHTTP 303HTTP GETが発生します。

両方のタイプが同じように動作するのは混乱していると思いますが、 ではありHTTP GETませんHTTP DELETE。

これにより、次の質問が発生しました。

  1. がエイリアスHTTP DELETEで呼び出されるとどうなりますか?
  2. それらが指している実際のオブジェクトを削除せずに、リストから参照を削除する適切な方法は何ですか?
4

2 に答える 2

0

URI は、リソース自体ではなく、リソースへの参照です。ある意味で、それらはすべて標準的です。異なる URI が同じリソースを識別する場合があります。彼らはまた、まだ存在すらしていない何かの担保権者であるかもしれません。「一方が他方なしでは存在できない」という概念は、アプリケーションに固有のものであり、REST の制約ではありません。理想的には、相互に依存する URI はありません。リソースを削除すると、それを指しているすべての URI は何も指しなくなります。または、少なくとも、URI が相互にではなくリソースを指している場合は、そうあるべきです。

アップデート：

RFC2396によると:

1.1 URI の概要:

...

リソース

リソースは、ID を持つものであれば何でもかまいません。おなじみの例には、電子ドキュメント、画像、サービス (たとえば、「ロサンゼルスの今日の天気予報」)、およびその他のリソースのコレクションが含まれます。すべてのリソースがネットワークで「取得」できるわけではありません。たとえば、人間、企業、図書館にある製本された本などもリソースと見なすことができます。

リソースは、エンティティまたはエンティティのセットへの概念的なマッピングであり、必ずしも特定のインスタンスでのそのマッピングに対応するエンティティではありません。したがって、リソースは、そのコンテンツ (現在対応しているエンティティ) が時間の経過とともに変化する場合でも、概念的なマッピングがプロセスで変更されない限り、一定のままにすることができます。

識別子

識別子は、ID を持つものへの参照として機能できるオブジェクトです。 URI の場合、オブジェクトは構文が制限された一連の文字です。

アップデート：

リソースが複数の URI を介してアクセス/変更可能である場合、正規のもの (応答のハイパーテキストに含まれる URI) を指定するのはアプリケーション次第だと思います。しかし、そうです、リソースではなく、(アプリケーションの観点から) 非正規の URI です。

于 2012-12-06T21:23:12.180 に答える
0

5.3.5. 消去

DELETE メソッドは、オリジン サーバーがターゲット リソースを削除することを要求します。このメソッドは、オリジンサーバーでの人間の介入 (またはその他の手段) によってオーバーライドされる場合があります。オリジンサーバーから返されたステータスコードがアクションが正常に完了したことを示している場合でも、クライアントは操作が実行されたことを保証できません。ただし、応答が与えられた時点で、リソースを削除するか、アクセスできない場所に移動するつもりでない限り、サーバーは成功を示すべきではありません。

**> 応答に含まれる場合、成功応答は 200 (OK) である必要があります。

アクションがまだ実行されていない場合は 202 (Accepted)、アクションが実行されているが応答に表現が含まれていない場合は 204 (No Content)。**

そう：

/users/{username} が /users/{userId} のエイリアスである場合 (一方が他方なしでは存在できません) > 前者を削除することは、後者を削除することを意味すると予想しています

エイリアスで HTTP DELETE が呼び出されるとどうなりますか?

「両方」のリソースを削除する必要があります。他なしでは存在できない場合、それらは同じリソースの異なる識別子であることを理解しているため、それらの1つを削除した後、次のリクエストは両方に対して404 Not Foundで応答する必要があります。

それらが指している実際のオブジェクトを削除せずに、リストから参照を削除する適切な方法は何ですか?

アップデート：

私の質問は、クライアントがリストから参照を削除したいことを示すためにどの HTTP メソッドを使用する必要があるかということです。

ユーザー (クライアント?) が実際のリソースを削除せずにリストから参照を削除したい場合、方法は 1 つだけです。クライアントは変更されたリストを含む PUT 要求をサーバーに送信する必要があります。つまり、既存のリストを新しいリストに置き換える必要があります。ユーザーが十分な権限を持っていない場合、応答で「403 Forbidden」が返されることがあります。

リソース (つまり、この場合はリスト) がクライアント側でキャッシュされることになっており、他のリソースの削除がこのリストに影響する場合、これの逆を行う (つまり、リストが変更されたときにユーザーに通知する) には、「通知する」と考えることができるアプローチのみが考えられます。 " ユーザーはキャッシュを使用します。例えば：

リクエスト

GET /list HTTP/1.1
Host: service.org

応答

HTTP/1.1 200 OK
Content-Type: application/...
Content-Length: ...
Cache-Control: private, max-age=0
ETag: a32lasdf

上記の応答の Cache-Control ヘッダー値「private, max-age=0」は、クライアントが表現をローカルにキャッシュできるという指示ですが、次の要求を毎回サーバーに送信する必要があります。

リクエスト

GET /list HTTP/1.1
Host: service.org
If-None-Match: a32lasdf

/list リソースが変更されていない場合、ETag 値は「If-None-Match」値と一致し、サーバーは「304 Not Modified」で応答でき、クライアントは何もする必要はありません。ただし、以前の削除アクションが /list に影響を与えた場合、ETag のハッシュ コードは "If-None-Match" ヘッダーで提供されるものとは異なるため、/list リソースの新しい表現がサーバーによって返されます。

于 2012-12-06T20:04:08.783 に答える