Gosto bastante da ideia de retornar algum dado que sirva para informar que um dia aquele conteúdo existiu. Bem melhor do que o 404, mas talvez só devolveria o status deletado e nada mais.

Gosto da ideia de retornar a estrutura inteira para que a interface precise se preocupar menos em como reagir a um caso desses. Inclusive, gosto da ideia de continuar retornando o owner_username para identificar de quem era a publicação e o deleted_at para saber quando ela foi removida. Mais para frente isso deveria ser retornado também na árvore de respostas para continar mostrando a árvore inteira. Essa ideia foi dada no passado por outra pessoa em outro momento, não lembro mais exatamente quando foi.

Sobre os endpoints, chegou a pensar em devolver tudo no mesmo endpoint /api/v1/contents/[username]/[slug]? Mas somente se esses dados forem solicitados via parâmetros.

Interessantíssimo e eu bolei 3 respostas de tanto que isso me deixou pensando 😂

Resposta 1

Se eu não me engano, sugeriram isso também no passado de incluir uma chave parent com todo o objeto ali dentro e juntanto com sua ideia ficaria show escolher quando receber o objeto parent, root (e até o children?) que pelo que entendi ali no [Edit] você sugeriu que daria para retornar pela chave tree, correto?.

Bom, com isso podemos tombar o /root, /children mas meu medo é começar a colocar muita complexidade dentro da mesma coisa, porque o jeito que está o model content hoje, principalmente o método findAll(), me dá medo. É muita complexidade que vai criando densidade num só lugar.

Resposta 2

Talvez possa ser interessante ter endpoints distintos, para justamente não precisar pagar o custo inteiro de demora quando você quer abrir o conteúdo principal para em seguida deixar as outras informações chegando e sendo exibidas de forma assíncrona. No caso do client web do TabNews isso não vai fazer diferença, pois acabamos pagando esse custo inteiramente na geração do estático.

Resposta 3

Meio que a continuação da Resposta 1 sobre o meu medo de complexidade estar em um único local e será que nessas horas a gente não deveria já estar usando um ORM para montar essas relações ou talvez usar GraphQL? No caso do ORM é sobre a facilidade de relacionar e buscar os conteúdos com uma interface mais limpa e mais segura do que temos hoje, e no caso do GraphQL de ter flexibilidade total em que dado buscar e da onde.

Não recomendo nenhuma dessas duas opções para agora, só queria deixar registrado para food for thought.

Sugestão de como avançar

1. Pelo fato de já termos o /children e agora o /root, sugiro implementar o /parent.
2. É uma movimentação muito fácil e isto vai trazer benefícios imediatamente, como isolar complexidade e normalizar a interface (de dados adicionais estarem disponíveis em sub-rotas). Gostaria de saber analisar qual o impacto de remover os dois JOINs das queries, mas não sei analisar isso hoje, então não sei se terá algum ganho de performance parar de fazer eles, tomara que tenha.
3. Com isso feito, sugiro mais para frente parar para pensar o que fazer com o model content e também se faz sentido manter a API em beta para propor novos breaking changes conforme o uso real dos clients.