Rudder

I suspect you don't want something like the status API?

http://www.rudder-project.org/doc-3.1/rest-api.html#_status

Or at least that maybe you want something like that, but on the public API.

Why do you need it to be unauthenticated ? (I mean, not that don't think you need it unauthenticated, but that if we have more use cases and example, it's easier to understand the whole need, like: do we want it to always be unauthenticated ? Do we want other information than just alive for authenticated people ? This king of things).

The status-API from localhost is enough, if you run your monitoring from localhost ;-) But this still does not cover the case when you messed up your apache config in a way, that you have broken some of the proxy-settings, so that the API does not work from the outside, just from localhost...

Since currently there is no differentiation between API Keys, adding an API Key to an external monitoring server just to test it can for example fetch /nodes/root, is a little bit overkill.

So the proposed solution is an unathenticated endpoint, that would return something machine-parse-able (like "OK"), or just indicate a return code of 200:OK, 500:NotOK, if the API Endpoint is up and running.

I could solve this by modifying/creating a new proxy rule in apache to expose that status-api to external, but it would be nice if this could be done in an upstream way.

Additional note: this would be solved if the access level of the API Keys could be customized, for example one just having the basic access to poll the status of the services...

Important note: the REST-way of creating a status like API is either to return a real status in JSON format:

{
  "status": "OK",
}

or a valid empty JSON response:

{ }

with a status code 200 or 500 depending on the application status.

I feel that just "OK" as a response body is not acceptable (a REST API should always return valid JSON, or an empty body)

I agree with Matthieu on the response format (which should follow other API responses format) and use adequate answers when not working

Regarding the response: I totally agree, that we'd need to return a valid json.

If you'd want to make it future-proof, you could add something like:

{ 
  "services": { 
    "database": "ok", 
    "ldap":     "ok", 
    "webapp":   "ok" 
  }
}

One thing to talk about is if this would require any kind of authorization.
If yes, the linked User Story #5798 would help to secure a monitoring-only API Key.

There was something similar implemented for gitlab 8.8 released recently:

http://docs.gitlab.com/ce/monitoring/health_check.html