Esta página foi traduzida pela API Cloud Translation.

Controle de versão v1 em feeds em lote

Nos feeds em lote, a versão de uma entidade é determinada pelo dateModified no envelope do feed:

{
  "@context": "http://schema.googleapis.com",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "@type": "DataFeed",
  "dataFeedElement": [
    /* All the items that are part of this feed go here */
  ]
}

Todas as entidades listadas no campo dataFeedElement terão o mesmo carimbo de data/hora, conforme listado no envelope.

Por exemplo, é possível ter o feed a seguir com duas entidades:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00:123-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/somerestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/somerestaurant/menu/1"
      ...
    }
  ]
}

Depois de recebidas e processadas, as entidades do cardápio e do restaurante seriam versão individual como "2018-12-28T06:30:00:123-07:00".

Controle de versão com atualizações incrementais

Ao enviar uma entidade usando atualizações de inventário, a versão é definida por no campo update_time (no caso de uma chamada de adição/atualização) ou o delete_time (no caso de uma chamada de exclusão). Como esses campos são opcionais, o o carimbo de data/hora padrão é definido como quando o Google recebeu a chamada.

Exemplo 1: update_time definido explicitamente

Suponha que a seguinte chamada incremental seja recebida em 2018-12-28T06:30:10:123-07:00 para um restaurante completamente novo. Esta é a solicitação POST HTTP para a entidade com ID "http://www.provider.com/somerestaurante", presumindo que o feed de dados use o esquema de inventário v1:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

Abaixo, o corpo do payload JSON contém o campo update_time. A entidade com ID "http://www.provider.com/somerestaurante" faz com que essa entidade seja versão 6:30:00, e não quando foi recebida (dez segundos depois, 6:30:10):

{
// This envelope is to be used for incremental.
  "entity": {
    // Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING&quot;
  },
  "update_time":"2018-12-28T06:30:00:123-07:00"
}

Exemplo 2: update_time definido implicitamente

Suponha que a seguinte chamada incremental seja recebida em 2018-12-28T06:30:10:123-07:00 para um restaurante completamente novo. Esta é a solicitação POST HTTP para a entidade com ID "http://www.provider.com/somerestaurante", supondo que o feed utilize a versão v1 esquema de inventário:

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json

Abaixo, o corpo do payload JSON não contém o campo update_time. A entidade com o ID "http://www.provider.com/somerestaurante" o que resulta em esta entidade com versão 6:30:10:

{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]";,
    "vertical": "FOODORDERING"
  }
}

Controle de versões entre lote e incremental

Uma entidade enviada ao Google é processada e veiculada somente se tiver a para a versão anterior. Geralmente, as entidades enviadas por lote levam alguns dias para serem processados, enquanto as entidades enviadas pela API incremental são processadas imediatamente.

Práticas recomendadas

Defina os campos update_time e dateModified em incremental e lote. respectivamente, de acordo com a data em que a entidade foi modificada nos sistemas.
Se um feed em lote (arquivo) listar mais de uma entidade de nível superior (por exemplo, você parear seus restaurantes com serviços e cardápios) e atualizar o carimbo de data/hora como os dados de uma entidade são atualizados.
Em chamadas incrementais, é altamente recomendável definir explicitamente o update_time.
Assim que uma chamada incremental é feita, o feed correspondente O carimbo de data/hora (dateModified) também é atualizado antes de ser buscado pelo Google novamente.

Exemplo

O Google busca o seguinte arquivo às 11h de 28/12/2018 para encontrar um arquivo completamente novo restaurante:

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T06:30:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

Essas entidades são processadas corretamente e têm controle de versões "2018-12-28T06:30:00-07:00". Como os feeds em lote levam algum tempo para serem processados, normalmente são exibidos dois dias depois.

Às 13h, no entanto, o sistema do parceiro tem uma atualização no telefone do restaurante. o que resulta na chamada incremental a seguir, que o Google recebe às 13:05 (5 segundos depois):

POST v2/apps/provider-project/entities/http%3A%2F%2Fwww.provider.com%2Fnewrestaurant:push
Host: actions.googleapis.com
Content-Type: application/ld+json
{
// This envelope is to be used for incremental.
  "entity": {
    //Note: "data" is not serialized as a string in our example for readability.
    "data": "[entity in JSON format serialized as a string]",
    "vertical": "FOODORDERING"
  },
  "update_time":"2018-12-28T13:00:00-07:00"
}

O update_time é fornecido explicitamente e é maior (mais recente) que o versão anterior (6h30 do mesmo dia), então a entidade "restaurante" agora é versão como "2018-12-28T13:00:00-07:00". No entanto, as entidades de cardápio e serviço ainda têm a versão "2018-12-28T06:30:00-07:00".

Houve uma chamada incremental, então o feed em lote é atualizado com o novo carimbo de data/hora correspondente. Além disso, as alterações correspondentes são aplicadas entidades relevantes (a entidade do restaurante tem seu número de telefone atualizado).

{
  "@context": "http://schema.googleapis.com",
  "@type": "DataFeed",
  "dateModified": "2018-12-28T13:00:00-07:00",
  "dataFeedElement": [
    {
      "@type": "Restaurant",
      "@id": "http://www.provider.com/newrestaurant",
      ...
    },
    {
      "@type": "Menu",
      "@id": "http://www.provider.com/newrestaurant/menu/1"
      ...
    }
    {
      "@type": "Service",
      "@id": "http://www.provider.com/newrestaurant/service/1"
      ...
    }
  ]
}

No dia seguinte (29/12/2018), às 23h, o feed é buscado novamente. O restaurante ainda tem a mesma versão (13h do dia 28 de dezembro), então essa entidade é descartada e a versão atual é mantida. No entanto, as entidades Menu e Serviço são atualizado para uma nova versão.

Carimbos de data/hora do sitemap

O cabeçalho de resposta last-modified no sitemap não afeta o mais recente de uma entidade. Isso afeta quando o feed é buscado pelo Google.

Práticas recomendadas

Atualizar o cabeçalho de resposta somente quando todos os arquivos estiverem atualizados e prontos para ser buscados.
Usar update_time e delete_time de maneira explícita no incremental.
Definir update_time, delete_time e dateModified para quando os dados mudarem por você.