2011-07-21 22 views
6

JSONをデータ言語として使用してWebサービスAPIを構築しています。サービスから返されるデータの構造を設計するには、欠損値の処理方法を決定する際にいくつかの問題があります。JSONで欠損値をnullまたは全く示さない

次の例を考えてみましょう:私のWebストアには、製品がまだリリースされていない可能性があるため、価格が未知である製品があります。 price: null(下記参照)を含めるか、この項目のpriceプロパティを単に省略しますか?

{ 
    name: 'OSX 10.6.10', 
    brand: 'Apple', 
    price: null 
} 

私の主な関心事は、APIをできるだけ簡単に使用できるようにすることです。明示的なNULL値は、priceが製品に期待できることを明らかにしますが、一方では無駄なバイトのようです。この特定の製品とは全く関係のない多数のプロパティが他の製品と関連しているかもしれません - これらを明示的にnullとして表示する必要がありますか?

{ 
    name: 'OSX 10.6.10', 
    price: 29.95, 
    color: null, 
    size: null 
} 

明示的または暗黙的なヌル値を優先するWebサービス設計には「ベストプラクティス」がありますか?デファクトスタンダード?それとも、それはユースケースに完全に依存していますか?

答えて

3

FWIW、私の個人的な意見:

私はprice: nullを含んでください(下図のように)、または私は単にこれの価格のプロパティを省略します項目?

"標準"フィールドの値をnullに設定します。 JSONはJavaScriptで頻繁に使用されますが、欠落したプロパティはnullに設定されたプロパティと同様に扱うことができますが、他の言語(Javaなど)では使用できません。フィールドが存在するかどうか最初にテストすることは不便なようです。値をnullに設定しますが、フィールドが存在するとより一貫します。

他の製品に関連する一方で、この特定の製品に全く無関係である特性の全体の束があるかもしれません - 私は同様にこれらのように明示的にnull示さなければなりませんか?

この商品には、商品に関連するフィールドのみが含まれます(たとえば、CDではpagesではありません)。これらの「オプション」フィールドを適切に処理するのはクライアントの仕事です。製品に関連する特定のフィールドの価値がない場合は、nullに設定してください。


既に述べたように、最も重要なことは、一貫性があり、どのフィールドが期待できるかを明確に指定することです。 gzip圧縮を使用してデータサイズを減らすことができます。

0

"ベストプラクティス"がわかりません。しかし、私は通常、私が必要としないフィールドを送信しません。 私は応答を読んだとき、値が存在する場合、私がチェック:

if (res.size) { 
    // response has size 
}