Here's the problem :While implementing a C# wrapper for an online API (Discogs) I've been faced to a dilemma : quite often the responses returned have mostly similar members and while modeling these responses to classes, some questions surfaces on which way to go would be the best.Example :Querying for a 'release' or a 'master' will return an object that contains an array of 'artist', however these 'artists' do not exactly have the same members.Currently I decided to represent these 'artists' as a single 'Artist' class, against having respective 'ReleaseArtist' and 'MasterArtist' classes which soon becomes very confusing even though another problem arises : when a category (master or release) does not return these members, they will be null. Though it might sound confusing as well I find it less confusing than the former situation as I've tackled the problem by simply not showing null members when visualizing these objects.Is this the right approach to follow ?An example of these differences :public class Artist{    public List<Alias> Aliases { get; set; }    public string DataQuality { get; set; }    public List<Image> Images { get; set; }    public string Name { get; set; }    public List<string> NameVariations { get; set; }    public string Profile { get; set; }    public string Realname { get; set; }    public string ReleasesUrl { get; set; }    public string ResourceUrl { get; set; }    public string Uri { get; set; }    public List<string> Urls { get; set; }}public class ReleaseArtist{    public string Join { get; set; }    public string Name { get; set; }    public string Anv { get; set; }    public string Tracks { get; set; }    public string Role { get; set; }    public string ResourceUrl { get; set; }    public int Id { get; set; }}Edit :I decided to keep things as simple as they can be : separated.There are few weird names but it'll always be less confusing than the previous situations.
Is it evil to model JSON responses to classes when they are mostly smilar?
class design;json
I've also ran into similar issues and I ended up going the other way -- check out disqussharp for visceral details. The tactic I used there was a common base class with variants for things that changed between different calls.I think having a single class -- or at least a common base class with the common properties -- is vastly more convenient for consumers and that is the way to go. There also isn't a law that says your classes that you return need to match the wire implementations if that makes more sense to callers of your library. If the service was that convenient then why would you be writing a wrapper in the first place?