オーダーのエンドツーエンド データフィードの構造は、リレーショナル在庫スキーマで定義されます。Ordering End-to-End データフィードは、次の最上位エンティティで構成されています。
Restaurant
エンティティ: サービスを提供しているレストラン。Service
エンティティ: サービスのタイミング、ロケーション、条件。Menu
エンティティ: 各レストランのメニューの詳細。
次の図は、Service
、Restaurant
、Menu
の各エンティティが 1 つのレストランをどのように表すかを示しています。
全般的なガイドライン
ファイルあたりのレストラン数: 各データファイルは 1 つのレストランを表し、関連する
Service
エンティティとMenu
エンティティを含める必要があります。レストランを検索するときに わかりやすいファイル名を使用しますデータファイル形式: データファイルは、改行区切りの JSON ファイル(ndjson 形式)にする必要があります。
DateTime と Time の値:
DateTime
またはTime
の値を必要とするプロパティでは、DateTime と Time の形式で指定されている形式を使用します。たとえば、DateTime
は2017-05-01T06:30:00+05:30
、Time
はT08:08:00+05:30
です。ID:
@id
プロパティは、エンティティ タイプ内のすべての一意のエンティティを識別するために使用します。最大文字数は 300 文字です。@id
は、そのタイプのエンティティの一意の識別子ですが、エンティティ間で ID が重複することがあります。たとえば、@id
プロパティをa16
に設定してService
エンティティを定義するとします。@id
がa16
の別のService
エンティティを作成することはできません。ただし、Menu
エンティティの@id
値としてa16
を使用できます。ID の生成: ID を安定させます。UUID を使用したり、フィードのアップロード後に ID を変更したりランダム化したりしないでください。これにより、エンティティ関連の問題のサポートが容易になります。
null 値: オブジェクトの代わりに値
null
を使用しないでください。省略可能なオブジェクトはフィードから除外する必要があります。
クライアント ライブラリ
[ツール] セクションのクライアント コード生成ツールを使用すると、注文に関するエンドツーエンドのデータフィードを検証できます。