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.
An error being thrown when the code can't handle the current situation is desirable. Failing in silence is the source of bugs, it's not the solution.
What you're implying is that you can fix your engine by turning off the "check engine" light. It doesn't solve the problem, it hides it, and that's going to bite you in the long run.
I am building a SDK that will simplify the use of my API.
The SDK is presumably going to handle the connection to the API, but it's not going to alter the data that comes from the API, I would assume. If not, I highly suggest reconsidering what exactly you expect your SDK to do, and question why that same behavior isn't already being exposed by your API as well.
Ideally, your SDK simply returns the code-consumer-friendly equivalent of whatever your API is already returning. Therefore, the API and SDK should be reusing the same enum. This specifically prevents the API from having enum values that the SDK doesn't, or vice versa.
Personally, I let my API and SDK depend on the same contract (= separate project which contains the enums, DTOs, ...) and have them be published at the same time. This ensures that each new version of the API comes with its own version of the SDK, thus ensuring that they are in sync with one another. Any consumer who wishes to target a specific version of the API can simply find the SDK with the matching version number.
Now, my question regarding SDK design/development is should I parse this "type" property as enum or as string?
Why is your API exposing an enum to its consumers if you are now going to question whether your SDK should be exposing an enum to its consumers? That makes little sense. The SDK should mirror the API for its data contract. If the SDK shouldn't expose an enum, neither should the API.
- Do your consumers care that this is an enum?
- Are they expected to handle this enum or know the closed list of values that it contains?
- Is this enum going to be used by the consumer to pass to the SDK/API?
If you answered "yes" to any of these, then you're probably going to want to expose the enum itself.
Whether you use an enum or a string depends on how you intend to handle it:
- Integer values are easy to handle, but lower on the human-readability scale.
- Strings are harder to handle but are more human-readable.
This is a decision you have to make: is the effort to parse strings worth having a more human-readable API?
If the SDK is the only intended consumer of the API, then you can just have the API return the integer value. If you wish for humans to be able to use your API directly (even if only developers who are debugging it), it may be worth converting the enum value to a string for readability's sake.
We can't make this decision for you. How you design your data contract is up to you. Use whatever makes the most sense for your use case. Whether you prioritize the SDK's concerns or the SDK consumer's concerns is at your discretion.
