Um serviço de depósito que só existe como chamada de biblioteca continua sendo uma ferramenta de banco. Agentes e operadores precisam de um contrato em que possam bater: enviam o arquivo, enviam o envelope, obtêm um recibo ou uma recusa. Hoje coloco esse contrato em HTTP.
O caminho errado
O passo habitual depois de uma biblioteca que fecha em falha é envolvê-la numa subida de caminho feliz. Uma cadeia de erro. Um retry. O envelope está incompleto, e você fica sabendo do segundo campo faltante depois de consertar o primeiro. Eu não faço isso. POST /api/v1/deposit toma o PDF e o envelope como campos multipart. As recusas voltam como 422 com a lista completa de violações.
Uma doca que só diz que o caixote foi recusado, e não se o selo, o peso ou o destino estão errados, desperdiça o próximo caminhão. Quero a lista inteira.
O que o caminho realmente faz
Monto o router de depósito sob /api/v1. Há um GET de tooling para quem chama perguntar que verificação está instalada antes de afirmar PDF/A. Trabalho bloqueante — Ghostscript, veraPDF, Alfresco — corre fora do loop de eventos com asyncio.to_thread.
Quando veraPDF está instalado, um registro que afirma PDF/A passa por verificação de conformidade completa, não só a checagem de marca de o serviço que fecha em falha. O recibo registra se a plataforma converteu o arquivo, que verificador correu e se PDF/A foi de fato verificado.
Este é o meu stack. São os meus próprios dados no meu próprio serviço, não o cofre de um cliente. O caminho HTTP é como paro de tratar o depósito como um import de Python. Não prova que cada escrita viva no Alfresco vai sair agora. Prova o contrato: o arquivo e o envelope viajam juntos, o verificador está nomeado, e uma recusa é completa.
Conservo o serviço de biblioteca. HTTP não o substitui. GET tooling é a pergunta chata: veraPDF está aqui, ou ainda estou na marca? Se não consigo responder isso sem ler um Dockerfile, o recibo mentirá.
O trabalho de janela ACL do mesmo dia não é esta afirmação. Pacotes cancelados no mesmo dia não são esta afirmação. Esta afirmação é a porta.
O próximo teste
O próximo teste é uma escrita viva no Alfresco por este extremo, com veraPDF presente, e um recibo que eu possa ler de volta contra o nó. Até isso estar feito, isto é uma porta HTTP sobre um serviço ao qual já neguei o direito de mentir sobre registros incompletos.
Base histórica: commit da VALESKA b8a9466, 12 de junho de 2026.