Inheritance in huge DTOs

Viewed 22

I have two applications, namely A and B.

A calls a rest API from B and passes a huge dto with 46 field in the body. I need all that data in application B. But as a new requirement, I must add 4 more field to this dto in order to handle another kind of request that needs all the other 46 fields. I managed it by using inheritance concept. Now I have 2 rest APIs to handle each type and there are some places where I have to use condition on type of the objects to avoid duplication. I thought I was preserving single responsibility principal.

But I wonder if it's the right way to have 2 rest APIs for such matter since it propagates complexity to client. Is it better to have a flat object and a single API?

And if inheritance is a good solution? (Because of duplications and conditions on type of objects).

And, is this OK to have such a huge dto and pass it around? Is there anyway I could avoid it?

1 Answers

Looks like you confuse REST APIs with endpoints, or the question does not make much sense. Having two endpoints for 2 operations e.g. POST /B/v1/x1 {body1} and POST /B/v1/x2 {body1+4fields} is totally ok. Posting two different request bodies to the same endpoint can be ok too if they do almost the same thing POST /B/v1/x1 {body1} vs POST /B/v1/x1 {body1+4fields}. As of DTO inheritance I prefer splitting it up to smaller DTOs and have a bigger DTO which is a composite of the smaller ones {p:{p1,p2,p3,...}, q: {q1,q2,q3,...}, f:{f1,f2,f3,f4}}. With this approach your additional 4 fields f can be optional. Generally speaking we avoid inheritance and follow to composition over inheritance principle. https://en.wikipedia.org/wiki/Composition_over_inheritance

Related