2

私はRESTAPIを構築していて、エラーを返すことを考えていました。現在、私の計画はhttpステータスコードを使用することでしたが、常に結果を返すこともありました。エラーが発生したかどうかにかかわらず、結果は次のようになります。

{
"Data":[the data],"
Errors":[the errors]
}

基本的に、エラーが発生した場合、4xxまたは5xxのHttpステータスコードが返され、返されたJSONのErrorsコレクションにはエラーに関する詳細が含まれ、Dataセクションはnullになります。呼び出しが成功した場合、要求されたデータを含むデータ要素とともに200のHttpステータスコードが返され、エラー要素は空になります。

これは、エラー情報を含むデータを返す良い方法でしょうか？

4

2 に答える 2

1

私の設計では、応答JSONオブジェクトに「data」プロパティと「errors」プロパティの両方を含めませんでした。

APIが成功した場合、「データ」のみを返します。また、httpステータスコードは2XXXです。

APIが失敗した場合、「エラー」オブジェクトを返します。httpステータスは、RFC2616のセクション10で定義されている仕様に従います。

エラーオブジェクトの例は次のとおりです。

HTTP/1.1 404 Not Found
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 100
Date: Thu, 08 Nov 2012 07:07:05 GMT
Connection: keep-alive

{
  "type": "error",
  "status": 404,
  "message": "Not Found",
  "help_url": "/api/help.html"
}
于 2013-03-12T13:52:22.070 に答える
0

私もこのアプローチを使用しています。私はこれが標準的な慣習に従っていないことを理解しています。しかし、何でも。どちらの方法でも議論できると思います。私個人としては、私のAPIは公開されていません（これらはすべて私のアプリケーションによって内部的に使用されています）。ですから、それは「状況によって異なります」という状況の1つだと思います。

私のAPIはすべて、Tテンプレートペイロードを使用して同じデータ構造を返します。コンシューマーは必要なものすべて（成功ステータス、エラーコード、エラーの詳細、そしてもちろんデータペイロード自体）を持っているため、データ構造自体は優れています。

このようにして、私のプレゼンテーション層はすべてのhttp応答を友好的な方法で均一に扱うことができます。

于 2019-07-17T23:57:37.513 に答える