Asset and Attribute API Calls deprecated typeIds (the list)

@tomfriesen​ Did you receive any feedback by Collibra?

Thank you for your feedback. My name is Roeland Herrebosch, I am a product manager at Collibra and I will try to provide some clarity.

When we started the introduction of the public id concept the goal was to have a more human-readable technical identifier that customers can use in workflow scripts or custom integration code. When your code logic needs to execute different actions for specific types, having UUIDs in your code makes it harder for a human developer to understand what type of content they are processing.

Initially our goal was to let public id fully replace UUID so we deprecated the typeId fields. Based on feedback we are changing our decision though. There are cases where you get the UUID of a type just to pass it to the next method, irrespective of what asset type/attribute type/relation type/... it is. In such case the actual value (whether it is a UUID or a public id) is only 'seen' by a computer and it does not make sense to force passing such interaction via public id. Therefore we decided to keep typeId and publicId fields in parallel. In the API documentation that gets released with the 2025.02 release, we will remove the deprecation  notices on the relevant fields.