JEP: Reliable method of Jupyter running status inspection.

[abaelhe]

i have design and implemented a reliable method to inspect Jupyter running status;

JEP for:

• 0. A major and integral reliability change, to the inspection method of broad used list_running_servers() function.

• 1. add a tag in /api response to recognize the Jupyter process no matter authenticated or not request; in a reliable, high performance, consistent, safety and achieve systematic design goals in a least code way.

refer to PR:

jupyter/notebook#5716

All checks/tests Passed.

[Zsailer]

Thanks, @abaelhe. Following up on this a bit...

@abaelhe is proposing a modification to the response model from the /api endpoint.

Right now, the /api endpoint in the notebook server returns only the version of the notebook server:

GET /api
{
  "version": "x.x.x"
}

The issue is that there is nothing in this payload that describes what application is returning this information. And it's certainly possible (maybe even likely) that another web application has an /api endpoint that returns a similar response model (i.e. with a "version" key).

As a point of concept, in jupyter/notebook#5716 @abaelhe is trying to ping jupyter servers to verify that they are running. Unfortunately, there is no non-authenticated endpoint that returns this information in a reliable way.

@abaelhe is proposing to add a key, i.e. "module", that names the responding application. i.e.:

GET /api
{
    "module": "JupyterNotebook",
    "version": "x.x.x"
}

Because this potentially affects many other applications, I asked @abaelhe to open an issue here. I think this is a small enough change, that it doesn't require any formal JEP, but I did want to get explicit approval from others before merging something like this into jupyter/notebook.

I'm in support of this change, but I'm curious what others think.

[mueslo]

FWIW jupyter/notebook#5791 would achieve the same thing