Resumo

  • O PubSubHubbub tirou do leitor de feeds a tarefa de perguntar repetidamente a cada site se havia novidades. No rascunho de 2010, o publicador avisava um hub; o hub buscava a atualização e a distribuía aos endereços de retorno dos assinantes. A rapidez dependia de um balcão de entrega.
  • A Recomendação WebSub de 2018 deixou o contrato mais nítido: 202 Accepted era recibo de pedido, ainda sujeito a validação; a assinatura expirava e o assinante precisava renová-la antes do prazo fixado pelo hub.

A pergunta repetida saiu da porta do site

Um leitor de feeds podia baixar a mesma lista de publicações muitas vezes ao dia, mesmo sem qualquer notícia nova. O rascunho PubSubHubbub Core 0.3 de fevereiro de 2010 propôs que o publicador anunciasse um hub no feed Atom ou RSS. Quando o feed mudasse, ele avisaria o hub. O hub buscaria o novo conteúdo e avisaria os assinantes em seus endereços de retorno.

O publicador deixava de responder à mesma pergunta de uma multidão. A lista de entrega ficava com um distribuidor. O rascunho tinha uma implementação de referência voltada ao Google App Engine, mas dizia que qualquer pessoa poderia operar um hub. A abertura do protocolo não dispensava um hub concreto para cada assinatura: a rota de uma atualização passava pelo intermediário anunciado pelo publicador.

O assinante enviava ao hub um endereço de retorno acessível pela rede. O hub encaminhava a esse endereço um hub.challenge, que deveria ser devolvido sem alteração. A prova impedia que terceiros usassem o endereço de alguém para assinar ou cancelar um feed sem sua vontade. O hub também mantinha os registros de assinaturas e organizava as notificações. O trabalho poupado na porta do site reaparecia no balcão de distribuição.

O recibo de 202 não entregava a notícia

O W3C anunciou o WebSub como Recomendação em janeiro de 2018, sob o novo nome do PubSubHubbub. A especificação daquele ano manteve publicador, hub e assinante, mas passou a tratar o tópico como recurso da Web, além dos feeds. O publicador anunciava tópico e hub; o assinante fazia um POST ao hub; o hub enviava o conteúdo por POST ao retorno.

O HTTP 202 Accepted marcava a chegada do pedido a um hub capaz de tratá-lo. Depois vinham validação e verificação da vontade do assinante. O hub podia recusar tópicos ou retornos segundo suas políticas, e a verificação exigia enviar um desafio e conferir a resposta. Pedido recebido, assinatura confirmada e atualização entregue não eram a mesma ocorrência. Um painel que parasse no 202 celebraria antes da festa.

O prazo era outro filtro. O rascunho de 2010 aceitava períodos de assinatura e descrevia uma checagem automática iniciada pelo hub para renová-los. Em 2018, a Recomendação exigiu que os hubs aplicassem a expiração e proibiu prazos perpétuos. No desafio de assinatura, o hub informava hub.lease_seconds; o assinante deveria pedir renovação antes do fim. O feed continuava público e atualizado, mas o envio programado a um retorno que perdeu o prazo podia acabar.

A norma admitia vários hubs e operadores independentes. O publicador escolhia quais anunciava. O hub escolhido decidia admissões, verificava retornos, guardava o relógio e distribuía. O publicador devia comunicar atualizações aos hubs, embora a forma dessa comunicação ficasse a cargo das partes. Depois o hub buscava o tópico e enviava o conteúdo, com tentativas de entrega limitadas por seus próprios critérios. Publicar, avisar, receber pedido, verificar, manter o prazo e entregar eram seis registros diferentes no caminho da chamada Web em tempo real.