オーダーのエンドツーエンド データフィードの構造は、リレーショナル在庫スキーマで定義されます。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を使用しないでください。省略可能なオブジェクトはフィードから除外する必要があります。
クライアント ライブラリ
[ツール] セクションのクライアント コード生成ツールを使用すると、注文に関するエンドツーエンドのデータフィードを検証できます。