Change Tags APIs to conform with rest of the APIs

[sureshms]

Tags APIs were coded long before other entities' APIs were added. Due to this, tag API does not follow the API convention that all the other entities are following. This issue makes backward incompatible changes to follow the same convention as glossaries.

TagCategory API changes

The name TagCategory is changing to Classification to adopt the more common terminology used in the industry. The API endpoints are changed as follows:

API functionality	Current API	New API
List tag categories	GET .../tags with no pagination	GET .../classifications that includes pagination
Create a tag category	POST .../tags	POST .../classifications
Get a tag category by name	GET .../tags/{category} that includes all the tags in the tag category	GET .../classifications/name/{category}. Children are no longer returned in the tag category. Use list tags APIs for this.
Get a tag category by id	Not supported	GET .../classifications/{id}
Update a tag category	PUT .../tags/{category}|PUT .../classifications`
Delete a tag category	DELETE .../tags/{id}|DELETE .../classifications/{id}`
Patch a tag category	Not supported	PATCH .../classifications/{id}
Get versions of a tag category	Not supported	GET .../classifications/{id}/versions
Get a specific version of a tag category	Not supported	GET .../classifications/{id}/versions/{version}

Tag API changes

Currently, only two levels of tag hierarchy are supported. The first level is called the primary tag and the next level is called the secondary tag. We are moving away from this to any levels of nested tag hierarchy similar to Glossary and GlossaryTerms.

API functionality	Current API	New API
List tags	Not supported	GET .../tags that includes pagination and use filters to get tags under a tag category or a parent tag
Create a tag	POST .../tags/{category} for the primary tag and POST .../tags/{category}/{primaryTag} for the secondary tag	POST .../tags with a field parent where parent tag term can be passed to create nested tag hierarchy
Get a tag by name	GET .../tags/{category}/{primaryTag} for primary tag and GET .../tags/{categoryName}/{primaryTag}/{secondaryTag} for secondary tag	GET .../tags/name/{fqn}
Get a tag by id	Not supported	GET .../tags/{id}
Update a tag category	PUT .../tags/{category}/{primaryTag} to update primary tag and PUT .../tags/{category}/{primaryTag}/secondaryTag to update secondary tag	PUT .../tags
Delete a tag	DELETE .../{category}/{id}|DELETE .../tags/{id}`
Patch a tag category	Not supported	PATCH .../tags/{id}.** Use this for renaming the patch, changing hierarchy, etc.***
Get versions of a tag category	Not supported	GET .../tags/{id}/versions
Get a specific version of a tag category	Not supported	GET .../tags/{id}/versions/{version}

Implementation notes

The resource classes TagResource and TagCategoryResource use EntityResource as the base class to eliminate a lot of duplicate code. Similarly, TagResourceTest and TagCategoryResourceTest use EntityResourceTest as the base class to reuse code.

[sureshms]

Tasks:

• [ ] Rename TagCategory to Classification
• [ ] Update UI code to use new APIs
• [ ] Update ingestion to use new APIs

[sureshms]

@ShaileshParmar11 the problem is fixed. There are still a lot of build errors because we expect under Classification a children field. This field is no longer supported and we should do similar changes as Glossary to get terms based on list .../tags with filter.