0

現在、サービスを設計しています。これは多層サービスであり、RESTインターフェースを使用して複数のクライアントからのデータを保存します。

URI内でリソースIDを受け入れる方法がわかりません。ユーザーがリソースを作成したとしましょう001。最初は自分用ですが、システム用には100番目です。

/resource/1ユーザー001が（ ）にGETしたときに何を返す必要がありますか/resource/{id}。彼のレコードを表示して、リクエストを実行しているユーザーに関連するURIを作成する必要がありますか？または、システムの1番目を返す必要がありますか（システムを表示するためのアクセス許可がないため、システムを拒否します）？

承認に関することを深く掘り下げたくはありませんが、このような状況にどのように対処すればよいか知りたいのです。後者を好む場合は、ユーザーに「OK、作成した最初のリソースを教えて」または「2番目のリソースを教えて...」、「最後のリソースを教えて..」、「100番目のリソースを教えて」と言わせるにはどうすればよいですか。私が作成したリソース」？

4

1 に答える 1

0

私はRESTの専門家であるとは主張していませんが、おそらくこれが私が行うことです。

ドメインモデルでは、ユーザーなしではリソースが存在できない場合は、次のようなURL呼び出しをモデル化してもまったく問題ありません。

GET /user/{userId}/resource  //Gets all resources of a user

一方、リソースがユーザーなしで存在できる場合、stackoverflowのこのリンクは、そのような呼び出しをモデル化するための優れた方法を提供します。

RESTful多対多可能ですか？

私たちのプロジェクトの1つで行ったもう1つのことは、リンクテーブル（UserResource table（id、userId、resourceId））があり、そのための一意のIDがあり、次のようなものがあったことです。

GET /userResource/{userResourceId}



 GET /userResource               //Retrieve all the resources user has access to

セキュリティが懸念される場合は、セキュリティをRest呼び出しと統合する方法に関するStackOverflowのリンクがあります。理想的には、そのようなロジックはサーバー側で処理する必要があります。通常、そのロジックをRESTURLに入れたくありません。

たとえば、

GET /resource  //Get all resources

ユーザーが誰であるかに応じて、ユーザーがアクセスできるリソースのサブセットのみを返します。

結論：権限を中心にリソースを構築しないでください。

繰り返しますが、私は専門家ではありません。ただ私の謙虚な見方。:-)

于 2012-10-26T19:50:38.417 に答える