web-dev-qa-db-ja.com

JSONのエラーコードは整数か文字列か?

私はバックエンドのWebサービスを設計しており、エラーが発生すると、それをJSONとしてフロントエンドに返します。このJSONには、フロントエンドがローカライズされた文字列にマップしてユーザーに表示するエラーコードが含まれています。

エラーコードは文字列か整数か?

{
  "error": {
    "code": 9900,
    "message": "Invalid ID"
  }
}

OR

{
  "error": {
    "code": "9900",
    "message": "Invalid ID"
  }
}

私は整数を自分で考えていますが、9900、9901のようなエラーコードがある場合など、固定長のエラーコードを返すほうが正しいのではないかと思っています。将来、コード12を送信したいと思います"9900""9901""0012"9900990112の形式で送信してください。

6
ruohola

私はテキストで行きます。数字のみを使用する文字列があっても問題ありません。経験則として、本質的に数学的でないものには整数を使用しないでください。つまり、適切な方法で値の加算または乗算を実行できる場合、それは数値です。それ以外の場合は識別子であり、テキストに固執する必要があります。実際にはおそらく問題ないでしょうが、実際には数値ではないものを保持するために整数型を使用すると、問題が発生する可能性があります。古典的な例は、整数を使用して郵便番号、つまり米国の郵便番号を格納することです。

5
JimmyJames

I18nへのマッピングと表現力の維持の両方を可能にするために、静的定数文字列を使用することをお勧めします。

このようなものは素晴らしいです:

{
 error: 'invalid_id'
}

そして、それをモジュールにスコープしてエラーの原因を特定し、重複を避けることもできます:

{
 error: 'auth.invalid_id'
}

または、オブジェクト内にhttp応答コードを追加することもできますが、これは応答自体には冗長ですが、HTTPに依存せずに他のタイプの通信を使用したいが、それでもセマンティクスを使用する場合に役立つことがあります。 。

{
 error: {
   key: 'auth.invalid_id',
   http_code: 401
 }
}
3
Diego d'Ursel

あなたはそれに数学をする必要がありますか? errorCode> 9000などの場合
整数を期待するものに渡す必要がありますか?
誤ってコード値にxを入力した場合、早期エラーが必要ですか?

これらすべてに「いいえ」と答えると、文字列を使用しない理由がわかりません。

12 vs 12についてのコメント については、それはプレゼンテーションの問題です。バックエンドはあなたがどちらをするかを気にする必要はありません。しかし、9999が最大のエラーコードであると想定しています。

2
candied_orange

誰もこれを取り上げたわけではありませんが、数値は通常i18nに適しています。クライアントは、表示するテキストを決定できます。多くの場合、クライアントはロケールに応じてテキストを翻訳する必要があります。そのため、国際化を処理するメカニズムがあるため、ほとんどの場合、これはクライアントで簡単に実行できます。

@Bellonの回答では、番号コードに慣れていない人でもエラーの内容を確認できるため、トラブルシューティングの目的でテキストも送信します。

1
Jon Raynor
{
    "code": 9900,
    "message": "Invalid ID"
}

最も適切なはずです。数値の標準では、引用符を付ける必要はありません。

https://www.json.org/

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

個人的には、HTTPで使用されるコード値に類似したコード値のパターンに従うことをお勧めします。そのため、エラーのカテゴリーをグループ化します(必ずしも数百でグループ化する必要はありませんが、おそらく数十でグループ化します)。

0
Bellons

整数を送信する場合は、整数として送信してください。エラーコード「abcde」がある場合は、文字列を送信します。 「12」と「0012」が異なるエラーコードの場合は、文字列を送信します。ただし、受信者が整数を必要とする場合は、整数を送信します。

0
gnasher729