[Docs]: Rename REST API -> HTTP API

Since the dstack API does not follow REST
standards, rename it from `REST API` to
`HTTP API`. Referring to it as a `REST API` has
proven confusing for users and partners, prompting
questions ("Why is everything a POST?").

Renaming the REST Plugin is out of scope for now.

Author: jvstme

.gitignore

@@ -26,5 +26,6 @@ uv.lock
 /src/dstack/_internal/server/statics
 
 profiling_results.html
+docs/docs/reference/api/http/openapi.json
 docs/docs/reference/api/rest/openapi.json
 docs/docs/reference/plugins/rest/rest_plugin_openapi.json

contributing/RUNNER-AND-SHIM.md

@@ -31,7 +31,7 @@ A container is started in either `host` or `bridge` network mode depending on th
 
 In `bridge` mode, container ports are mapped to ephemeral host ports. `dstack-shim` stores port mapping as a part of task's state. Currently, the default `bridge` network is used for all containers, but this could be changed in the future to improve container isolation.
 
-All communication between the `dstack` server and `dstack-shim` happens via REST API through an SSH tunnel. `dstack-shim` doesn't collect logs. Usually, it is run from a `cloud-init` user-data script.
+All communication between the `dstack` server and `dstack-shim` happens via HTTP API through an SSH tunnel. `dstack-shim` doesn't collect logs. Usually, it is run from a `cloud-init` user-data script.
 
 The entrypoint for the container:
 - Installs `openssh-server`
@@ -52,7 +52,7 @@ The entrypoint for the container:
   - Wait for the signal to terminate the commands
 - STEP 5: Wait until all logs are read by the server and the CLI. Or exit after a timeout
 
-All communication between the `dstack` server and `dstack-runner` happens via REST API through an SSH tunnel. `dstack-runner` collects the job logs and its own logs. Only the job logs are served via WebSocket.
+All communication between the `dstack` server and `dstack-runner` happens via HTTP API through an SSH tunnel. `dstack-runner` collects the job logs and its own logs. Only the job logs are served via WebSocket.
 
 ## SSH tunnels
 

docs/blog/posts/dstack-metrics.md

@@ -31,9 +31,9 @@ difference is that `dstack stats` includes GPU VRAM usage and GPU utilization pe
 Similar to `kubectl top`, if a run consists of multiple jobs (such as distributed training or an auto-scalable service),
 `dstack stats` will display metrics per job.
 
-!!! info "REST API"
+!!! info "HTTP API"
     In addition to the `dstack stats` CLI commands, metrics can be obtained via the
-    [`/api/project/{project_name}/metrics/job/{run_name}`](../../docs/reference/api/rest/#operations-tag-metrics) REST endpoint.
+    [`/api/project/{project_name}/metrics/job/{run_name}`](../../docs/reference/api/http/#operations-tag-metrics) HTTP endpoint.
 
 ## Why monitor GPU usage
 

docs/docs/concepts/projects.md

@@ -66,4 +66,4 @@ You can find the command on the project’s settings page:
 <img src="https://dstack.ai/static-assets/static-assets/images/dstack-projects-project-cli-v2.png" width="750px" />
 
 ??? info "API"
-    In addition to the UI, managing projects, users, and user permissions can also be done via the [REST API](../reference/api/rest/index.md).
+    In addition to the UI, managing projects, users, and user permissions can also be done via the [HTTP API](../reference/api/http/index.md).

docs/docs/guides/migration/slurm.md

@@ -27,7 +27,7 @@ Both Slurm and `dstack` follow a client-server architecture with a control plane
 |---|---------------|-------------------|
 | **Control plane** | `slurmctld` (controller) | `dstack-server` |
 | **State persistence** | `slurmdbd` (database) | `dstack-server` (SQLite/PostgreSQL) |
-| **REST API** | `slurmrestd` (REST API) | `dstack-server` (HTTP API) |
+| **API** | `slurmrestd` (REST API) | `dstack-server` (HTTP API) |
 | **Compute plane** | `slurmd` (compute agent) | `dstack-shim` (on VMs/hosts) and/or `dstack-runner` (inside containers) |
 | **Client** | CLI from login nodes | CLI from anywhere |
 | **High availability** | Active-passive failover (typically 2 controller nodes) | Horizontal scaling with multiple server replicas (requires PostgreSQL) |

docs/docs/reference/api/rest/index.md docs/docs/reference/api/http/index.mddocs/docs/reference/api/rest/index.md renamed to docs/docs/reference/api/http/index.md

@@ -1,8 +1,8 @@
 ---
-title: REST API
+title: HTTP API
 ---
 
-The REST API enables running tasks, services, and managing runs programmatically.
+The HTTP API enables running tasks, services, and managing runs programmatically.
 
 ## Usage example
 

mkdocs.yml

@@ -134,6 +134,7 @@ plugins:
         "examples/clusters/a4/index.md": "examples/clusters/gcp/index.md"
         "examples/clusters/efa/index.md": "examples/clusters/aws/index.md"
         "docs/guides/migration.md": "docs/guides/upgrade.md"
+        "docs/reference/api/rest/index.md": "docs/reference/api/http/index.md"
   - typeset
   - gen-files:
       # TODO: convert these to hooks (schema reference migrated)
@@ -276,7 +277,7 @@ nav:
               - dstack import: docs/reference/cli/dstack/import.md
           - API:
               - Python API: docs/reference/api/python/index.md
-              - REST API: docs/reference/api/rest/index.md
+              - HTTP API: docs/reference/api/http/index.md
           - Environment variables: docs/reference/environment-variables.md
           - .dstack/profiles.yml: docs/reference/profiles.yml.md
           - Plugins:

scripts/docs/gen_openapi_reference.py

@@ -14,7 +14,7 @@
     {"url": "https://sky.dstack.ai", "description": "Managed server"},
 ]
 app.version = DSTACK_VERSION or "0.0.0"
-output_path = Path("docs/docs/reference/api/rest/openapi.json")
+output_path = Path("docs/docs/reference/api/http/openapi.json")
 output_path.parent.mkdir(parents=True, exist_ok=True)
 new_content = json.dumps(app.openapi())
 if not output_path.exists() or output_path.read_text() != new_content: