Czy podział na obiekt służący jako request i reponse to dobra praktyka? Np. mam obiekt DTO wiadomości.
Pierwszy obiekt służy do wysyłania nowej wiadomości do kontrolera
public class MessageRequest {
private String toUsername;
private String subject;
private String text;
}
a drugi do zwracania wiadomości z dodatkowymi polami
public class MessageResponse {
private final Long id;
private final String sender;
private final String recipient;
private final String subject;
private final String text;
private final Date date;
private final Date dateOfRead;
}
Zastanawia mnie to, ponieważ w jednym z większych projektów Netflixa na GH znalazłem, że twórca stosuje jeden obiekt zarówno do wysyłania jak i zwracania. Wygląda on mniej więcej tak.
public class Application extends ... {
private final ApplicationStatus status;
private final String type;
private final Set<String> configs;
private final Set<String> dependencies;
private final String setupFile;
private final String version;
private final String user;
private final String name;
private final JsonNode metadata;
private final Set<String> tags;
private final String id;
private final Date created;
private final Date updated;
}
Według mnie w tym przypadku użytkownik jest mylony jakoby miał podać podczas tworzenia obiektu np. ID czy version.(Oczywiście, że nie musi wypełnić tych pól, bo nie są one brane pod uwagę podczas tworzenia w bazie, ale i tak według mnie jest to niepotrzebne). Dziwnie by to wyglądało np. używając narzędzia swagger, ponieważ wyświetlona byłaby propozycja podania ID.
Dlatego w mojej aplikacji postanowiłem rozdzielić to na 2 różne obiekty. Wydawało mi się, że to dobre rozwiązanie, jednak teraz jestem trochę niepewny. Jak według Was powinno to wyglądać?