Esta página foi traduzida pela API Cloud Translation.

Controle de versões v1 em feeds em lote

Nos feeds em lote, a versão de uma entidade é determinada pelo campo 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, você pode ter o seguinte feed 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"
      ...
    }
  ]
}

As entidades de menu e de restaurante, depois de recebidas e processadas, seriam controle de versões individualmente como "quot;2018-12-28T06:30:00:123-07:00"".

Controle de versões com atualizações incrementais

Ao enviar uma entidade usando atualizações de inventário, a versão é definida pelo campo update_time (no caso de uma chamada de adição/atualização) ou pelo campo delete_time (no caso de uma chamada de exclusão). Como esses campos são opcionais, 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. Veja a solicitação POST HTTP para essa entidade com o ID "http://www.provider.com/somerestaurant" supondo 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" resulta no fato de que essa entidade tem versões 6:30:00 e não quando foi recebida (10 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"
  },
  "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. Veja a solicitação HTTP POST para essa entidade com o ID "http://www.provider.com/somerestaurant" supondo que o feed 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 não contém o campo update_time. A entidade com o ID "http://www.provider.com/somerestaurante" portanto, essa versão tem a 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 em lote e incremental

Uma entidade enviada ao Google só será processada e veiculada se tiver a versão mais recente. As entidades enviadas em lote geralmente levam alguns dias para serem processadas, enquanto as entidades enviadas pela API incremental são processadas imediatamente.

Práticas recomendadas

Defina os campos update_time e dateModified em incrementos e lotes, 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ê pareia seus restaurantes com serviços e menus), atualize o carimbo de data/hora conforme os dados de uma entidade são atualizados.
Em chamadas incrementais, recomendamos que você defina explicitamente o campo update_time.
Quando uma chamada incremental é feita, o carimbo de data/hora do feed correspondente (dateModified) também é atualizado antes que o Google o busque novamente.

Exemplo

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

{
  "@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 e passam a ter o controle de versões "2018-12-28T06:30:00-07:00" Como os feeds em lote levam tempo para serem processados, eles geralmente são veiculados dois dias depois.

Às 13h, no entanto, o sistema do parceiro tem uma atualização do número de telefone do restaurante, o que resulta na seguinte chamada incremental, que o Google recebe às 13h05 (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) do que a versão anterior (6h30 do mesmo dia), então a entidade do restaurante agora recebe uma versão como "2018-12-28T13:00:00-07:00". No entanto, as entidades de menu e serviço ainda têm controle de versões como "2018-12-28T06:30:00-07:00".

Como houve uma chamada incremental, o feed em lote é atualizado com o novo carimbo de data/hora correspondente. Além disso, as mudanças correspondentes são aplicadas às entidades relevantes (a entidade do restaurante tem o 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 de 28 de dezembro), então essa entidade é descartada e a versão atual é mantida. No entanto, as entidades Menu e Service são atualizadas com uma nova versão.

Carimbos de data/hora do sitemap

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

Práticas recomendadas

Atualize o cabeçalho de resposta somente quando todos os arquivos estiverem atualizados e prontos para serem buscas.
Use explicitamente update_time e delete_time de forma incremental.
Defina update_time, delete_time e dateModified como quando os dados mudarem.