web-dev-qa-db-ja.com

パブリックAPIで（列挙）タイプを表す方法

私は自分のクライアントで使用し、将来的に公開したい単純なAPIに取り組んでいます。異なる「タイプ」を持つことができる「アイテム」オブジェクトがあります。タイプはCの「typedef enum」で、今のところは：

typedef enum {
    ItemTypeBool,
    ItemTypeNumber,
    ItemTypeDate,
} ItemType;

（将来的に追加する可能性があります）

私はそれを整数として、または定義された「文字列」として転送するべきかどうか疑問に思っています。 JSONは次のようになります。

整数の場合：

{
  "name": "The name",
  "type": 0,
   ...
}

文字列の場合：

{
  "name": "The name"
  "type": "boolean"
   ...
}

このためのベストプラクティスがあるかどうかと思います。整数を維持すると、コードがわずかに簡素化され、帯域幅が減少しますが、開発者にとって文字列は覚えやすくなります。プロジェクトで作業したことを覚えています。1=画像、2 =音声、3 = htmlなど、本当の意味はありません。

ですから、私が考慮すべき他の側面を知っているなら、私はあなたに尋ねています。

apipatterns-and-practicesenum
33
Julien

文字列を提供します。数字は無意味です。あなたはあなた自身のコードでそれらを使用しません、そうです（あなたは列挙値をラップしています、それは基本的に文字列です）-なぜこれらの数値を使わなければならないことでユーザーを罰しますか？

数値を公開する場合の唯一のプロ-これらを解析するのが簡単です。でもねえ、あなたのことを気にかけてる人。 APIクライアントに注意してください。

あなたが文字列を提供する場合-クライアントにとってより簡単です。 「4は17のために廃止されました」のようなことを言う必要はありません。代わりに少し難しい構文解析を行いますが、それで問題ありません。

両方を提供しないでください：ユーザーとして、私は疑問に思います

  • どちらを使用しますか？どちらも？ [ドキュメントを読むために]
  • 同じことを言う2つの方法があるのはなぜですか？それらは微妙に異なりますか？ [ドキュメントを読むために]
  • 両方を指定し、不一致がある場合はどうなりますか？それは文句を言うでしょうか？どちらが優先されますか？どれ？ [ドキュメントを読むために]

ご覧のとおり、理由もなく、たくさんのドキュメントを読んでいただいています。

42
iluxa

文字列。

Jsonの強みの1つは、人間が読めることです。今から半年後に出力をデバッグするとき、「0」は何も伝えません。

一部のフレームワークは自動変換も行います。使用していない場合は、コードをドライに保つために自分でコンバータを作成できます。

ただし、これにより投票が行われます。

2
Evgeni

ベストプラクティスは、誰がAPIを使用しているかによって異なります。消費者の生活を楽にしようとしている場合は、C、Java、iOS、python、RubyでAPIを消費できるサンプルコードを提供する必要があります。これらのラッパーには、列挙型を含めることができます、jsonでintを使用し、jsonを解析してenumがすでに設定されているオブジェクトに変換し、このオブジェクトをユーザーのコードに返します。

あなたができるもう一つのことは両方を提供することです。例えば：

{
  "name": "The name",
  "typeId": 0,
  "type": "ItemTypeBool"
   ...
}

または、APIに最適なものに応じてtypeおよびtypeStrを使用できます。

そして、これらは冗長であり、アプリケーションに最適なものを選択するのは開発者の責任です。

ここでjsonを見てください： https://dev.Twitter.com/docs/api/1/get/search Twitterには冗長データ（idおよびid_str）を提供する例がありますが、これはjsonクライアントは、jsonの「数値」から長い整数を解析できず、数字が失われないように文字列が必要です

1
portforwardpodcast