Doc and / or API wrong for "SMAPI Healthy"

[Bischoff]

Reference: https://cloudlib4zvm.readthedocs.io/en/latest/restapi.html#smapi-healthy

1. In the doc, one reads:

   7.4.1. Report healthy of SMAPI

   but correct English would rather be "Report health of SMAPI".

2. In the doc, one reads:

   * Request:
   
    `X-Admin-Token header  string  Admin-token, which is stored in /etc/zvmsdk/token.dat. You need
   put this into header to request for a auth-token. Then you can send a request with this auth-token.`

   I think this is meant for another API call, and it should rather be:

   
   * Request:

None

3. In the doc, one reads:

smapi_healthy body dict Status of SMAPI healthy

but the API returns a dictionary named `SMAPI` instead of `smapi_healthy`. Which one is wrong?

4. In the doc, one reads:

continueousFail body integer The count of continueous fail.

and this is consistent with what the API returns, but correct English is "continuous", not "continueous" (no "e").

5. In the doc, one reads:

healthy body integer Whether SMAPI is healthy.

but the API returns a boolean instead of an integer. Which one is wrong?

6. This paragraph 7.4.1 lacks an example. Here is one:

{ "SMAPI": { "totalSuccess": 0, "totalFail": 0, "lastSuccess": "", "lastFail": "", "continueousFail": 0, "healthy": true } }

7. The return value from the API above lacks the "usual" fields: `rs`, `overallRC`, `modID`, `rc`, and `output`.

Is that intentional?

I hope that helps.

[jichenjc]

The return value from the API above lacks the "usual" fields: rs, overallRC, modID, rc, and output.

that's good question, I think I missed this part during the design and implementation phase conceptually we should add those usual fields ..

the API itself has not been well designed and might need further polish , need find some time to do that later

[Bischoff]

The return value from the API above lacks the "usual" fields: rs, overallRC, modID, rc, and output.

that's good question, I think I missed this part during the design and implementation phase conceptually we should add those usual fields ..

the API itself has not been well designed and might need further polish , need find some time to do that later

Fixed in #813.