O que muda no roteiro original
O texto de novembro de 2023 prometia explicar um script em Node.js usando googleapis e feedparser. O corpo preservado, porém, contém apenas a descrição das etapas, sem o programa completo. Também terminava na publicação automática e sugeria copiar um código de autorização para o console. A revisão organiza o processo para rascunhos e corrige a referência ao antigo fluxo OAuth fora de banda. Trata-se de um roteiro documental atualizado, não de um sistema executado e aprovado em uma conta real.
- Rascunho como etapa segura: Postagem preparada para revisão editorial, sem acionar a publicação como saída automática.
A documentação da API Blogger v3 informa que posts.insert recebe o identificador do blog e aceita o parâmetro isDraft. Para o fluxo aqui proposto, ele deve ser definido explicitamente como true. O título e o conteúdo compõem o recurso enviado; a operação exige autorização OAuth. Essa escolha técnica separa criar um rascunho de publicar. Ainda assim, um rascunho altera a conta e só deve ser criado após o responsável autorizar o blog, as fontes e o escopo da tarefa.
A biblioteca googleapis é mantida pelo Google para acesso às suas APIs em Node.js. Ela não substitui um leitor de RSS nem resolve, por si, direitos de uso e duplicação. O feedparser foi citado no original, mas sua página não pôde ser recuperada nesta consulta; não se afirma compatibilidade de uma versão específica. Antes de implementar, será preciso selecionar versões suportadas, ler a documentação do analisador e testar o conjunto em ambiente separado do blog de produção.
Do RSS à fila de revisão editorial
Comece por delimitar a origem: quais feeds poderão ser consultados e qual material pode ser reutilizado. Na especificação RSS 2.0, um item pode trazer título, descrição, link, identificador guid e data pubDate; nem todos esses campos são obrigatórios. Portanto, escolher a primeira entrada ou a maior data não é uma regra suficiente para todos os feeds. O projeto precisa tratar data ausente ou inválida e manter um registro de itens já processados. Como decisão de implementação, use a identidade da fonte junto ao identificador estável disponível e documente o critério alternativo quando ele faltar. O objetivo é uma seleção auditável, sem presumir que toda consulta traz conteúdo novo.
Depois, produza uma versão local para revisão: título, resumo autorizado, link de origem e anotações de procedência. Trate o HTML recebido como entrada não confiável, removendo scripts e atributos perigosos antes de qualquer envio. A proposta editorial é começar com um único item e conferir o resultado. Não copie imagens ou o artigo integral apenas porque aparecem no feed. A disponibilidade técnica da informação não demonstra permissão para republicar todo o material.
- Origem e uso autorizados: Defina feeds permitidos e registre o que pode ser aproveitado antes de preparar o envio.
- Identidade sem duplicação: Guarde uma chave estável do item e o resultado da criação para conferir novas tentativas.
- Rascunho antes de publicar: Defina isDraft como true e confirme o estado retornado antes de avançar para outro item.
Na autenticação, não reproduza o antigo OAuth out-of-band, no qual o usuário copiava o código para o aplicativo: o Google informa que esse fluxo foi bloqueado para apps em produção. Aplicativos de computador têm alternativas documentadas, como retorno por endereço de loopback, conforme o tipo de cliente. A autorização deve ocorrer no navegador pelo fluxo suportado. Tokens e credenciais exigem armazenamento protegido; não devem aparecer no artigo, nos registros de erro ou no repositório.
Com o cliente autorizado e o conteúdo aprovado para envio, a integração pode solicitar a criação do rascunho e guardar o ID retornado. Se ocorrer timeout, não repita imediatamente como se nada tivesse sido criado: o servidor pode ter aceitado a primeira operação. Esta é uma recomendação de projeto para evitar duplicações. Faça a reconciliação do registro local com o estado do blog e só então decida a próxima tentativa. Falhas de acesso exigem revisão da autorização, não exposição do token.
A implementação deve começar em modo de simulação, que lê e prepara o item sem escrever no Blogger. Depois, um teste autorizado com um rascunho permite conferir título, corpo, caracteres, links e estado. Registre o que foi solicitado e o que a API respondeu, sem incluir segredos. Só amplie a quantidade depois de validar também itens repetidos, datas ausentes e interrupções. Este artigo não fornece um pacote executável, pois o código completo não estava preservado e nenhuma integração foi testada. Ele define o percurso para construí-lo com responsabilidade. A publicação continua como decisão editorial separada, após a leitura humana do conteúdo e das condições de reutilização.
Veja Mais
- Autoria, licenças e remuneração de quem cria conteúdo digital
- Como verificar imagens, licenças e políticas antes de publicar no Blogger
- Artigos úteis para leitores e mecanismos de busca
