Skip to main content
deleted 2 characters in body
Source Link
John
  • 783
  • 2
  • 7
  • 22

I am building a SDK that will simplify the use of my API.

The problem is if when I have to return property of type enum. For example, I use strings instead of int for displaying enum such as

{
  "type": "CAR"
}

instead of

{
"type": "1"1
}

Now, my question regarding SDK design/development is should I parse this "type" property as enum or as string? If I parse it as enum, I am always in a danger that if new enum value is added, this conversion will throw an error. If I tend to anticipate it, and catch that error, I am still ending up with either a caught exception or invalid enum value.

On the other hand if I return it as string this problem is gone, but I am expecting that client (client app) keeps track of all the enums and enum changes.

What would be an expected approach? or if there is another way to handle this, please suggest.

I am building a SDK that will simplify the use of my API.

The problem is if when I have to return property of type enum. For example, I use strings instead of int for displaying enum such as

{
  "type": "CAR"
}

instead of

{
"type": "1"
}

Now, my question regarding SDK design/development is should I parse this "type" property as enum or as string? If I parse it as enum, I am always in a danger that if new enum value is added, this conversion will throw an error. If I tend to anticipate it, and catch that error, I am still ending up with either a caught exception or invalid enum value.

On the other hand if I return it as string this problem is gone, but I am expecting that client (client app) keeps track of all the enums and enum changes.

What would be an expected approach? or if there is another way to handle this, please suggest.

I am building a SDK that will simplify the use of my API.

The problem is if when I have to return property of type enum. For example, I use strings instead of int for displaying enum such as

{
  "type": "CAR"
}

instead of

{
"type": 1
}

Now, my question regarding SDK design/development is should I parse this "type" property as enum or as string? If I parse it as enum, I am always in a danger that if new enum value is added, this conversion will throw an error. If I tend to anticipate it, and catch that error, I am still ending up with either a caught exception or invalid enum value.

On the other hand if I return it as string this problem is gone, but I am expecting that client (client app) keeps track of all the enums and enum changes.

What would be an expected approach? or if there is another way to handle this, please suggest.

Source Link
John
  • 783
  • 2
  • 7
  • 22

SDK design: Should I parse enum as string or as enum?

I am building a SDK that will simplify the use of my API.

The problem is if when I have to return property of type enum. For example, I use strings instead of int for displaying enum such as

{
  "type": "CAR"
}

instead of

{
"type": "1"
}

Now, my question regarding SDK design/development is should I parse this "type" property as enum or as string? If I parse it as enum, I am always in a danger that if new enum value is added, this conversion will throw an error. If I tend to anticipate it, and catch that error, I am still ending up with either a caught exception or invalid enum value.

On the other hand if I return it as string this problem is gone, but I am expecting that client (client app) keeps track of all the enums and enum changes.

What would be an expected approach? or if there is another way to handle this, please suggest.