Introduce a centralized library to call the Checkmk API

[godspeed-you]

The code to contact the Checkmk API is redundantly placed all over the modules. This projects aims to centralize this code into a single library to make our lifes more easy. Later changes may be done in one single place instead of changing several dozens of code lines.

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

• Currently, if the API headers or other static information is changed, this needs to be adapted in an unclear amount of files and code lines.
• Everytime a new API call to Checkmk is added, bugs or slightly different behaviour may be introduced.

What is the new behavior?

• The centralized file may be called by every module to have a defined set of functionality returned information.
• This set may be used to derive a module specific class to address specific requirements.
• The result of this API call is stored in a defined and clearly structured data set. This allows to automatically provide a clear and reliable set of information after the API call.

Other information

This PR contains a migrated module as an example on how to use this new library. The changes have been reduced to an absolute minimum to minimize potential bugs. So potential further refactorings may be skipped to have this change less complex.

[lgetwan]

I really like the way you unified and simplified the API calls!
I have a question regarding the definition of the inheriting class, though. In some modules, there are multiple, different POST or GET calls. How would you define the related
def post(self)
calls for those?

[msekania]

related #176

[godspeed-you]

I prepared a second module to use the API library (user) and I had minor problems/changes to the API.py - but I guess, you're referring more to the group modules, where you can post a single or multiple groups. For the users module, it felt very natural, to just use get/post/put/delete. If there is more than one put-call, I would probably use a suffix (e.g. def put_group and def put_groups.

On users (in the pipeline) I worked with the following:

def get(self):
   ... 

[...] 

def module():
    ... 
    user = UserAPI()
    result = user.get()

[msekania]

@godspeed-you,

First of all thanks,

Concerning module, in essence it should at least cover all already implemented usage in different modules, otherwise it will be yet another modules which one has to adjust manually per module and not the central one.

[godspeed-you]

Would it be okay to add other modules one after another? It's a lot of work and I would prefer to take my time to avoid to introduce new Bugs.

In the other Side it's very time consuming keeping a feature branch in sync with the main/devel for a longer period.

[lgetwan]

I agree to update the modules one by one. And I agree, it's probably easier to have separate feature branches for each module change.
Thanks for updating the user module, as well!

[msekania]

@godspeed-you,

when structure is fixed and accepted, I will also help with group modules.

[lgetwan]

Looks fine!