API for topics

[sahithyaravi]

Reference Issue

What does this PR implement/fix? Explain your changes.

Topic APIs - For adding topics for datasets based on a topic model

• topic_add - to add a topic to a dataset
• topic_delete - to delete a topic added to a dataset

We are going to use this in the new website to group datasets/filter datasets by topic.

This API can be accessed only by admin users.
In future, we will add a get API to get topics per dataset or list datasets by topic.
.

How should this PR be tested?

Any other comments?

• Since the API can only be used by admin, I tested this locally with the admin key to see if it works.
• The unit test added only checks if an error occurs when a non-admin user accesses these APIs.
• For the same reason I did not add an example. Please let me know if I need to add an example (With a note to fill in admin key before usage for instance)

[PGijsbers]

I think these functions should be marked private (i.e. underscore prefix and not imported/added to __all__ in __init__.py to avoid accidental imports). This allows the code itself to signal to users that it shouldn't be used by them.

Not writing an example is fine, given we don't expect a regular user to use this functionality. However, for later reference it might be good to add a section to the api documentation with admin-only functions.

I would like @mfeurer to weigh in on this though. What are your thoughts on how to add admin-only operations? The main alternative I considered would be to perhaps add a separate submodule for them, but as long as there aren't many of them this makes more sense to me.

[mfeurer]

I would like @mfeurer to weigh in on this though. What are your thoughts on how to add admin-only operations? The main alternative I considered would be to perhaps add a separate submodule for them, but as long as there aren't many of them this makes more sense to me.

I don't have a strong opinion on this, but it looks like it would be a bit nicer in a separate admins package.

[PGijsbers]

Okay, in that case I propose to just go with the private methods for now, and refactor to an admin package when we have more admin features.