サブリソースの状態を変更するためのRESTメソッド

Question

現在、リソースと有効なエントリの2つの異なるサブリソースを持つリソースを表すREST APIがあります。以前はこの構造は変更できませんでした。エラーが発生した場合はエラーが発生し、有効なエントリがあれば有効なエントリとして残ります。 JSON出力の例を次に示します。

GET /resource/1 
{ 
    "resourceId" : 1, 
    "errors" : [ 
    { "id": 1, "errorDetails" : "it isn't right" } 
    ], 
    "validData" : [ 
    { "id": 1, "message" : "it's good!" } 
    ] 
} 

エラーを訂正して有効にするための要件が​​発生しています。だから、本質的に操作した後の結果は、補正処理がエラーを修正していないは、a）指定されたパラメータなどの新しいエラーエントリを作成し、いくつかの余分なパラメータを取るだろう

GET /resource/1 
{ 
    "resourceId" : 1, 
    "errors" : [], 
    "validData" : [ 
    { "id": 1, "message" : "it's good!" }, 
    { "id": 2, "message" : "Corrected, old data was : it isn't right" } 
    ] 
} 

であるか、またはb）は、新規に作成しますエラーが修正されたので有効な入力。

RESTの観点から、これを表現する最良の方法は何ですか？ は、これまでのところ私は、次のアイデアを持っている：

1. は、パラメータを持つPUT/DELETEエラーにすなわちPUT /リソース/ 1 /エラー/ 1を持っています。これにより、/ resources/1/errorsまたは/ resources/1/validDateの下に新しいサブリソースが作成されます。
2. PUT/resource/1にはPUTがあります。一方の側から他方の側へ移動することによって全体としてリソースを変更する

Answer 1

オプション1を使用してエラーのリソースを作成します。何かを意味し、何らかの動作もします除去された）。実際に何が行われるのかを判断するには、サーバ側で何らかの処理が必要である（私が正しく理解すれば）必要があるので、POSTにする必要があります。

何らかの理由で「重要」なものはすべてリソースである必要があります。したがって、オプション2は最適ではないようです。

マイナーノート：既にID番号がのすべてがである必要があります。これは「データ」でも同じです。また、これらのもののIdを明示的に漏らす本当の理由がない限り、私はむしろIdの代わりにこれらのものにURIを返すでしょう。