A dissociação supera o DRY no REST?

Estou criando uma API REST para expor a maioria das funcionalidades de uma API Java existente. Ambas as APIs são para uso interno dentro da minha organização; Não preciso projetar para uso externo. Eu tenho influência sobre as duas APIs, mas estou implementando a REST. A API Java continuará sendo usada para aplicativos locais (não está sendo "aposentada"), mas a API REST será usada para novos desenvolvimentos significativos.

Algumas das classes da API Java são simplesmente dados (beans com propriedades, getters, setters). E pelo menos alguns deles fazem sentido transmitir (de alguma forma) pela API REST como dados (que serão empacotados para XML ou JSON). Por exemplo, uma classe que armazena informações sobre uma máquina servidor. Sou confrontado com a seguinte opção para essas classes de dados: Eu ...

1. expor a classe Java original (ou uma subclasse) diretamente na API REST, ou
2. criar uma nova classe de transferência de dados (padrão DTO) especificamente para a API REST?

De qualquer maneira, terei classes de transferência de dados REST; a questão é se deve anotar os originais ou criar novos (que podem estar próximos das cópias dos originais). Pode haver outras opções, mas vou me concentrar principalmente nessas duas.

Argumentos para o 1:

• SECA (não se repita)
• Mais rápida de implementar
• Mais fácil de atualizar a API REST

Argumentos para o # 2:

• E se a API REST precisar ser versionada separadamente da API Java? (Isso é um pouco provável.)
• E se houver alterações significativas nas classes de dados Java, como remoção de propriedades, adição de comportamento ou alterações na hierarquia de classes? (Isso também é um pouco provável.)

A conclusão é que parece uma troca entre DRY (# 1) e desacoplamento (# 2).

Estou inclinado a começar com o número 1 e, se surgirem problemas, passar para o número 2 mais tarde, seguindo a orientação ágil de não criar o que você não pode provar que precisa. Isso é uma má ideia; devo começar com o número 2 se acho que posso acabar lá de qualquer maneira?

Existem argumentos / consequências importantes ausentes nas minhas listas?

Boa pergunta, basta colocar, desacoplar. Esse é o caminho a seguir aqui, você não deseja estar vinculado à versão do java.

Há um cenário que você não dissocia: se sua tecnologia permitir que objetos não específicos de tipo sejam enviados por fio, ou seja, se você pode usar os objetos java atuais agora como um YAGNI e a substituição por um diferente o tipo que você personaliza será um drop-in simples que não quebrará nada devido às informações de tipo que passam por fio. Então, basicamente, se as informações de tipo não cruzarem o fio, você poderia YAGNI nisso.

Apenas tenha muito cuidado e esteja atento para que as atualizações da sua versão java não alterem nenhum desses objetos. Caso contrário, apenas desacople agora e não se preocupe, acho que depende de quanto tempo você tem se tiver uma escolha.

No entanto, se as informações de tipo passarem por todo o fio no seu protocolo, uma introdução simples de novos tipos quando os tipos java subjacentes forem alterados pode não ser possível e pode ser um esforço maior. Se for esse o caso, seguir o YAGNI agora significa acumular dívida e risco técnicos relacionados à sua tecnologia subjacente.

Pessoalmente, eu apenas me desacoplaria agora.

Além disso, o DRY não entra nisso porque você não escreveu as partes subjacentes, portanto não está duplicando o código e, portanto, não terá repetidas dores de bugs por toda parte, o que é a principal preocupação do DRY (e manutenção geral) problemas que novamente você não terá porque não possui duplicatas para manter)

Os principais argumentos para o número 1 são a facilidade de implementação e atualizações, mas isso atende aos seus requisitos?

Nos seus argumentos para o número 2, você indica que a API Java e a API REST provavelmente podem mudar independentemente. Isso significa que são preocupações separadas e você não está se repetindo usando classes separadas. Só porque duas coisas parecem iguais, não significa que são iguais.

Sua API REST não precisa seguir a mesma estrutura que seu modelo de dados

Ao implementar o REST, certifique-se de criar uma API externa intuitiva e mapeie-a para suas classes internas de modelo de dados. Isso permite que você altere cada um independentemente do outro, levando a APIs que podem durar décadas .

Portanto, a dissociação é o caminho a seguir aqui.