0

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.

  • Not sure if there's a published standard on this or not, but minimally I'd expect you to at least stick to a single standard for key casing (e.g. PascalCase or camelCase or underscore_separated), rather than having id and name as lower case (or possibly camelCase) with the rest as PascalCase. – Paul Jan 15 at 22:21
  • the Casings is not an issue here, it's just typo in this question. – yekanchi Jan 15 at 22:23
  • It appears you don't want the API creating any objects at all. You want to hand it existing objects with blanks to fill in. Am I missing something? – candied_orange Jan 15 at 23:05
  • @candied_orange i want the API to create the object and i just want to fill the necessary data. – yekanchi Jan 16 at 8:00
  • @yekanchi then why are you sending in fields with empty string values? – candied_orange Jan 16 at 13:15
2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.