1

複数のリソースを渡すリクエストを処理する方法について混乱しています。

次の階層があります。プロジェクトには成果物があり、成果物にはドキュメントがあります。プロジェクト -> 成果物 -> ドキュメント。

ドキュメントに固有のカスタム アクション、たとえば change_status については、/projects/1/deliverables/1/documents/1/change_status などのルートがあります。この時点まではすべて良好です。

しかし、複数のドキュメントで change_status を変更したい場合のベスト プラクティスは何でしょうか? /projects/1/deliverables/1/documents/change_status (ドキュメント ID の配列を渡す) は、「ドキュメント」の後に特定の ID が存在する必要があることを理解しているため、RESTFul のようには見えません。

/projects/1/deliverables/1/change_status (ドキュメント ID の配列を渡す) は、2 つの理由で納得できません。まず、成果物コントローラーが呼び出されます (レールの慣例により)。また、ドキュメントではなく成果物のステータスを変更しているようです。ドキュメントでステータスを変更できることを考えると、結果の URL は紛らわしいと思います。特に、ステータスを成果物にも変更できる場合（ステータスを成果物またはドキュメントに変更することとどのように区別しますか。この場合、URL は同じになります） .

SO基本的に、RESTFulで複数のリソースを処理するリクエストを処理する方法について混乱しています。任意のヘルプ/説明をいただければ幸いです。ありがとう！

4

2 に答える 2

2

基本的な RESTful URL 規則は、すべての場合に厳密に適用されることを意図したものではありません。標準の CRUD シナリオを超えた場合に何が意味を成すかについて、最善の判断を下す必要があります。

成果物内のドキュメントのステータスを常に変更する予定がある場合は、(提案したように) /projects/1/deliverables/1/documents/change_status を使用します。

成果物やプロジェクト全体でドキュメントのステータスを変更する予定がある場合は、/documents/change_status のようにドキュメントに直接アクセスする別のルートを使用します。

いずれにせよ、document_id パラメータの配列を渡す必要があります。

于 2012-07-10T22:59:05.923 に答える
0

また、change_status ではなく、URL でステータス サブリソース「status」を呼び出す必要があります。

PATCH /documents/status HTTP/1.1

approved=true&id=7&id=12
于 2012-11-24T13:01:59.540 に答える