This proposes a REST API to support drives directly in the backend; see friendly preview.
First version
It is identical to Jupyter Server contents API with the addition of a optional drive query argument.
The rational to use a query arg instead of making it part of the path parameter is to avoid trouble of splitting the drive and the path.
To support the copy between drives, the PUT request is extended to supported two types of body request: one with the file content and one with the source file path for copying it. For now the source is supposed to concatenate the drive (optional) and the path in a pattern: ((?P<drive>[^:]+):)?(?P<path>.+). To align with the introduction of the drive query argument, it may be better to use an object for source: {"path": string, "drive": string}.
Second version
Set the drive as URL path parameter {drive}/{path}
Remaining questions:
How to download a file? JupyterLab is currently downloading files from the files endpoint that does not support Drive
This proposes a REST API to support drives directly in the backend; see friendly preview.
First version
It is identical to Jupyter Server contents API with the addition of a optional
drivequery argument.To support the copy between drives, the
PUTrequest is extended to supported two types of body request: one with the file content and one with the source file path for copying it. For now the source is supposed to concatenate the drive (optional) and the path in a pattern:((?P<drive>[^:]+):)?(?P<path>.+). To align with the introduction of the drive query argument, it may be better to use an object forsource:{"path": string, "drive": string}.Second version
Set the drive as URL path parameter
{drive}/{path}Remaining questions:
filesendpoint that does not support Drive