列挙型を公開する RESTful サービスがあります。
それらをローカライズされた文字列またはプレーンな整数として公開する必要がありますか?
私の傾向は、サービス エンドで簡単に変換できるように整数に傾いていますが、その場合、列挙型の意味を知るために、クライアントはどこかからローカライズされた文字列のリストを取得する必要があります。無駄に余分なステップを作成しているだけですか?
RESTful API で一般的に行われていることについて、私が見つけることができる情報はほとんどないようです。
編集：
わかった。人々のペットに関する情報を保存する Web サイトを書いているとしましょう。AnimalType列挙型を持つことができます
0 Dog
1 Cat
2 Rabbit
etc.
人々が特定のペット リソース (/pets/1たとえば/pets/types.
または、両方を提供する必要がありますか?
クライアントに公開したい一貫性のあるRESTfulAPIのサームで考える必要があると思います。
コードで列挙型を使用するかどうかは、実装の詳細です。クライアントが彼の実装で列挙型を使用するかどうかは、抽象化のレベルが異なるだけなので、あなたは知らないか、気にする必要はありません。
API設計が最初で、実装が続きます。
これらの列挙型を使用して、クライアントにどのような種類の情報を返したいかについてもう少し洞察を提供していただければ、より正確な答えを出すことができます。
今のところ、整数IDと文字列の説明が、RESTfulリソースへの呼び出しで返したい情報や状態の説明に関連している場合は、両方をjsonまたはxmlドキュメントでラップして返す必要があります。
API コンシューマーがこれらの値をプログラムで使用する (つまり、値に基づいて決定を下す) ことが意図されている場合は、ローカライズされていない文字列を使用します (十分に文書化され、安定していることを確認します)。Enum 値はローカル開発フレームワークではローカライズされておらず、開発者はこれに対処することに慣れていますが、なぜ Web API が異なるのかわかりません。
API コンシューマーがこれらの値をユーザーに表示することを意図している場合は、ローカライズされた文字列を使用します。
両方を実行できるようにする場合は、ローカライズされていない文字列 (ID) を使用しますが、これらの ID をローカライズされた文字列にマップするために、別の API エンドポイント/リソース (またはオフライン ドキュメント) を提供することを検討してください。
なんらかの理由でメッセージ サイズを本当に気にする場合 (たとえば、1 つのメッセージにこれらのものが何千もあり、それがモバイル シナリオである場合) にのみ、数値 ID を使用することを検討します。