Verifique a unicidade e o formato de um slug

A ferramenta primeiro exige um formato previsível com letras minúsculas, dígitos e hífens simples; depois, compara a proposta válida com os slugs existentes informados por você. Um formato inválido sempre gera erro, mesmo que o mesmo texto esteja na lista. Resultados válidos indicam claramente se o slug é único e se foi encontrada uma colisão exata.

Valide o slug antes de verificar a disponibilidade

Um resultado de unicidade só é útil quando o valor proposto pode fazer parte de uma URL com segurança. Informe o candidato e os slugs já utilizados pelo seu site, aplicativo ou repositório de conteúdo. São aceitas letras inglesas minúsculas de a a z, dígitos de 0 a 9 e hífens entre grupos não vazios. Maiúsculas, espaços, sublinhados, pontuação e hífens iniciais, finais ou repetidos são rejeitados. A ordem é rigorosa: o formato é validado antes da busca por correspondência. Portanto, um candidato inválido que também esteja na lista produz erro de entrada inválida, não um resultado comum de colisão. Isso oferece uma regra estável para formulários, importações em massa e implantações. Respeite o limite de comprimento e envie a coleção atual como uma matriz de strings; nenhuma normalização oculta altera os valores enviados.

Interprete corretamente as colisões exatas

Para um candidato bem formatado, a resposta inclui o slug enviado, confirma que o formato é válido e apresenta dois valores complementares: único e colisão. Existe colisão quando a string exata aparece pelo menos uma vez na lista fornecida. A comparação é intencionalmente exata: a ferramenta não remove prefixos, decodifica escapes de URL, apara itens nem considera frases semelhantes como a mesma página. Por exemplo, guia-produto e guias-produto continuam sendo rotas válidas diferentes. Esse comportamento mantém a resposta determinística e deixa para seu aplicativo as regras sobre nomes reservados, prefixos regionais, redirecionamentos ou restrições do banco. Itens duplicados na lista não mudam o resultado. Como a lista é a fonte de verdade da solicitação, atualize-a quando vários editores ou processos puderem reivindicar rotas simultaneamente.

Use a verificação na publicação e na implantação

Execute a verificação o mais perto possível do momento em que uma rota é reservada. Em um editor, valide depois de gerar o slug a partir do título e repita quando houver alteração. Em um site estático, reúna primeiro os caminhos de saída e teste cada proposta contra os já aceitos. Em uma API ou migração, trate erros de entrada como falhas de qualidade a corrigir e colisões como decisões de nomenclatura. A operação é determinística, não usa rede e não armazena dados, sendo adequada para testes e builds reproduzíveis. Porém, ela verifica e não reserva: outro processo pode reivindicar o slug depois da leitura da lista. Para gravações concorrentes, mantenha também uma restrição única no banco ou faça uma reserva atômica ao salvar.