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 restaurante, depois de recebidas e processadas, seriam versionadas individualmente como "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 o momento em que 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 HTTP POST 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

Confira abaixo o corpo do payload JSON com o campo update_time. A entidade com o ID "http://www.provider.com/somerestaurant" resulta em uma versão com o horário 6:30:00 e não quando foi recebida (dez segundos depois, às 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

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/somerestaurant" resulta na 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 só é 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 como incrementais e em lote, respectivamente, de acordo com o momento em que a entidade foi modificada nos seus sistemas.
Se um feed em lote (arquivo) listar mais de uma entidade de nível superior (por exemplo, você associa restaurantes a serviços e cardápios), 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.
É imperativo que, depois que uma chamada incremental for feita, o carimbo de data/hora do feed correspondente (dateModified) também seja 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 recebem a versão "2018-12-28T06:30:00-07:00". Como os feeds em lote levam tempo para serem processados, eles normalmente são veiculados dois dias depois.

No entanto, às 13h, 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 (cinco 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). Portanto, a entidade do restaurante agora tem a versão "2018-12-28T13:00:00-07:00". No entanto, as entidades de menu 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 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 "Serviço" 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. Isso 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 ser buscados.
Use explicitamente update_time e delete_time de forma incremental.
Defina update_time, delete_time e dateModified para quando os dados mudarem no seu fim.