... | ... | @@ -25,10 +25,10 @@ The basic structure of the config file is: |
|
|
```
|
|
|
|
|
|
The keys in the first level must be the service names. They can be choosen freely and are displayed in the API response.
|
|
|
Under every key, there must be another JSON object containing the `"friendy_url":` and `"protocol":` keys. The friendly URL is always displayed in the API response. Depending on the test protocol and it's configuration, this URL is taken as the URL which will be used to determine if the service is up. But mostly, a seperate test URL can be set, which is not displayed in the API response.
|
|
|
Under every key, there must be another JSON object containing the `"friendy_url"` and `"protocol"` keys. The friendly URL is always displayed in the API response. Depending on the test protocol and it's configuration, this URL is taken as the URL which will be used to determine if the service is up. But mostly, a seperate test URL can be set, which is not displayed in the API response.
|
|
|
|
|
|
|
|
|
# Protocol that is used to test the service (`"protocol":` key)
|
|
|
# Protocol that is used to test the service (`"protocol"` key)
|
|
|
|
|
|
The `"protocol":` key must always contain the `"type":` key. Currently, it can be set to `"http"`, `"teamspeak"`, or `"minecraft"` (take a look at #1 for updates on protocol support). The also mandatory `"config":` key must be configured depending on the protocol type. See below for documentation for them. Most of the options under the `"config":` key are optional. If none of them are set, the `"config":` key can be empty (`{}`) but **not** omitted.
|
|
|
|
... | ... | |