Had a discussion that i felt i needed some external input on. Normally always use interfaces instead of concrete types (on lists, injectable services and so forth). For example in lists i just pass around IEnumerable instead on List and so forth. The same applies for custom types (ICustomClass instead on CustomClass). This works fine for webapi, logging frameworks like serilog and so forth.
But i ran into some custom code which couldnt handle serializing interfaces due to implementation details. The argument for keeping concrete types instead of interfaces (and instead of adjusting serialization) was summarized to this post. And i can see if you work with XML documents there might be a need for concrete types to ensure serialization / deserialization if that is required (?).
EDIT: Realized i might have been unclear / vague in my description. I personally would never Create an interface for a DTO itself (like IDTO). Since i do not see any point to it. I likely will never replace it and i dont inject it for example. I WOULD however often resort to have that DTO contain an IEnumerable property in favor of a List or Type[] for example. I cant remember any time ive had an custom class represented by an interface since i ntry to always keep them simple. But perhaps there is a scenario i could raise regarding this where the same questioning might persit.
Soo what i would gladly get some input on:
Is there any good concrete technical arguments for avoiding interfaces in DTOs and responses (that might be serialized when returned through api or logdumping for example) in a normal REST API that outputs json?