Quickly:
- instead of:
http://localhost:8888/api/contents/Untitled.ipynb
- try:
http://localhost:8888/files/Untitled.ipynb
More in-depth:
The GET {:base-url}/api/contents/{:path} API endpoint returns… JSON API responses, as described in the best-effort OpenAPI Spec.
best-effort in that it’s not validated against that spec, per-request, at runtime, and can be changed by extensions
This provides rich metadata one typically wouldn’t get from a typical “dumb” static HTTP endpoint, and critically allows for listing a directory, which is not something HTTP provides by default.
Something missing from the spec is the GET {:base-url}/files/(:path) endpoint, as it’s not really thought of as an API, I suppose: this is an alternate view of the contents that provides traditional HTTP files.
The standards-based play, long term, would indeed be to unify Jupyter Contents with HTTP using an existing standard such as WebDAV RFC 3648… but that’s a lotta XML, and it’s not a W3C or IETF standard. That being said: it is supported by a large number of clients, including most operating systems’ built-in file browsers. And the spec hasn’t changed in 20 years, which is actually a killer feature for a standard.