Is It good practice on API design to use different object model for getting object and creating

Question

While mostly every company got it's standard on APIs, the question just came out after that one of my colleagues stated we must use different object models for creating and getting objects from API.

To be clear, he states that when you want to get the object from the API you will receive an object like this:

{
 id: '1111',
 name: 'SomeName',
 createdBy: '',
 createdDate: '',
 yitle: 'oh my titlte',
 details 'Some Dets'
 persons: 'whom may concern'
 products: [{p1}, {p2}]
}

But when you want to create an object of the same entity you must send the following object to API:

{
 name: 'blahbla',
 title: 'valhvalh'
}

So you shouldn't send the properties that are not needed ass empty. Because i'm using C# it's easier for me to work with one class object for a known entity, so i think that when i want to create the object instance i can send the following object:

{
  id: '',
  name: 'SomeName',
  createdBy: '',
  createdDate: '',
  title: 'oh my titlte',
  details '',
  persons: '',
  products: ''
}

Mentioning that we don't have a high traffic and bandwidth is not issue i thought why we should do excess work to gain nothing but more complex code. He added this is an standard used in social medias too witch i myself could't agree on and could't provide any evidence.

The Question is that is this an standard in API's? and if yes what's the gain here and what is it for.

Answer 1

Conceptually, I don't like throwing around objects that are only considered "valid" when they have a specific subset of properties filled in. I find it confusing - when I'm creating it, what do I need to set in order for it to be "correct"? When I'm consuming it, how do I know if it's got everything it needs?

Having an object with name, title, createdBy, details etc but somehow having to "just know" that only name and title are valid during creation is not good design IMO.

In C# specifically I would probably get around this by making the object properties get-only and have specific factory constructors to make it explicit what is needed:

class Foo
{
    public string Name {get; private set;}
    public string Title {get; private set;}
    public string SomethingElse {get; private set;}

    public static Foo CreateWithName(string name, string title)
    {
        return new Foo()
        {
            Name = name, 
            Title = title
        };
    }

}

That way I know I'm constructing a valid object that only has what it needs for the job at hand.

If you can't, or don't want to do that, then I'd stick with dedicated objects for constructing and retrieving the data because it's more explicit. Only pass around what you need, it's less confusing.