5

resource がPersonあり、 person にネストされた resource があるとしSomeResourceます。次のシナリオでは、どのステータス コードを返す必要がありますか? また、その理由は何ですか?

/Person/1/SomeResource (SomeResource does not exist)
/Person/1/SomeResource (Person does not exist)

404 は両方のシナリオで使用する必要があると思いますが、誰もが同意するわけではなく、その理由を知りたいです。Personそれは基礎となるリソースであり、そのリソースのSomeResource単なる「プロパティ」でありSomeResource、最初のシナリオでは何も返さないが、2 番目のシナリオでは 404 を返す必要があると主張できます。それはオプションかもしれないと思いますが、私はまだ 404 の方が好きです。私がまったく好きではないもう 1 つのシナリオは、エラーの説明を付けて 500 を返すことです。これは、私がディスカッションで聞いた代替手段でしたが、消費者は私が好きではない例外に対してプログラムする必要があります。私にとっての 500 は、何かがうまくいかず、それについては何もできないことを意味します。

問題は、404 を取得した場合、なぜ 404 を取得したのかがわからないという議論でした。それは、404 がPerson存在しなかったためなのか、存在しなかったためになのかということSomeResourceです。

更新 1: たぶん、次SomeResourceのような別のリソースに分割する必要があります

/SomeResource/1

のような応答を返します。これは、{data: {the data}, person: {person data}}両方が欠落している場合にのみ 404 を返しますが、データが欠落している場合は、空のデータで 200 が返されます。

更新 2: 使用するステータス コードを把握したと思います。その時点で、決して実行してはならない要求、つまり悪い要求であると考えているため、その人が存在しない場合は 400 です。が存在しない場合は、存在していたがネストされたリソースが欠落していたSomeResourceため、404 を使用します。Person

4

1 に答える 1

1

特定のURIは、単一の「リソース」で識別することを目的としていることを覚えておくと役立つ場合があります。意味的には、URI構造は「ネストされた」リソースの概念をサポートしていません。2つのリソースがあるようです：Person＆ある種の関係があるSomeResourceシナリオでは。この関係を表すために、次のような構造を試すことができます。SomeResourcePerson

GET /person/1

{
    name: "Some Value",
    someResource: {
        "Href": "http://yourSite.com/someresource/123",
        "Title": "Get some resource for this specific person"
    },

    // other key/value pairs as appropriate...
}

このようにして、アプリケーション固有の意味で400と404をオーバーロードすることはありません。クライアントが有効なPersonの結果を受け取った場合、クライアントは単にSomeResourcehrefを呼び出し、適切な404を受け取るか、SomeResource 123既存のものに依存しません。URIが存在しない場合、PersonURIが存在しないため、URIを呼び出すと適切に404が返されます。

于 2012-07-11T13:35:10.543 に答える