8

RESTfulな方法で考えると、POSTを使用して、リソースとそのサブリソースを1回の呼び出しで作成するのは正しいですか？私のアプリケーションには、リソース/notices/{notice}とサブリソースがあり/notices/{notice}/photos/{photo}ます。はなし{photo}では存在できませんが{notice}、{notice}必ずしも写真を持っているとは限りません。通常、私は最初に通知を作成するためにPOSTを実行し、次に写真を追加するために別のPOSTを実行する必要があります。

ここで、写真を直接添付して通知を作成できるようにし、/notices/{notice}両方/notices/{notice}/photos/{photo}のリソースを説明するマルチパートコンテンツ（JSON通知のために、写真のバイナリ）。サブリソースに対してのみLocationヘッダーを返すと思います。

基本的に、Androidクライアントがサーバーに2つのPOSTリクエストを送信して、写真付きの通知をアップロードしないようにするためです。これは正しいです？それともRESTの原則を侵害していますか？それらを別々に保ち、2つの異なる要求を行うことを検討する必要がありますか？それとも、写真を通知とは別のエンティティと見なすのは間違っていますか？/notices/{notice}PUTを使用して写真を追加し、リソースとしてのみ保持する必要がありますか？

どちらが最善の解決策ですか？

4

2 に答える 2

4

はい、親リソースの作成と同時にサブリソースを作成しても問題はありません。親URLの下にあるものはすべて、アップロードするリソースの一部であるか、リソースに属しているため、これを行うPUT代わりに使用することもできます。POST

編集：

ここで、写真を直接添付して通知を作成できるように/notices/{notice}し/notices/{notice}/photos/{photo}、1回のPOSTリクエストで通知を作成できるようにします。/notices/{notice}/photos/{photo}

これには同意しません。コレクションリソースのURLにPOSTすることをお勧めします/notices。通知とその写真を単一の表現（リクエスト本文）として提供します。バックエンドは、通知と構成写真の両方のリソースを作成します。

于 2013-01-11T11:37:28.680 に答える
1

多くの場合、それは不可欠ですが、複数の編集/作成は、RESTfulアーキテクチャスタイルによって正式に対処されていません。

コレクションの一部で障害を報告する必要がある場合に問題が発生し、障害の原因が異なる場合は問題が悪化します。

それは、クライアントが特定のトランザクション/会話で前進する方法を見つけるために不可欠な適切なハイパーメディアコントロールを選択することに影響します。

したがって、私の提案は、ネストされたリソースを作成するためにPOSTを歌うのではなく、ネストされたサイクルまたはPOSTリクエストを使用することです。これにより、各リソースの状態の変化に対処するのがより簡単で明確になります。

于 2013-01-11T11:44:08.113 に答える