Anwendungen-API

Anwendungen neueste zuerst auflisten, maximal 500 pro Seite. Namen sind Bezeichnungen und müssen nicht eindeutig sein; eine Anwendung wird über die ID adressiert. next_cursor ist die Position der zuletzt zurückgegebenen Zeile, solange weitere Zeilen vorhanden sind; geben Sie ihn als after mit denselben Filtern für die nächste Seite zurück. next_cursor ist auf der letzten Seite null.

Streamt ein CLI-erzeugtes tar.gz direkt in eine begrenzte dauerhafte Staging-Umgebung. Metadaten werden in Headern übertragen, sodass das Archiv nie base64-kodiert oder vom Server als JSON materialisiert wird.

Der Proxy vor der API beendet eine Anfrage, die er nicht innerhalb von etwa 100 s beantwortet hat, sodass ein großes Archiv bei langsamer Uplink-Verbindung hier fehlschlägt; POST /api/applications/uploads sendet das Archiv stattdessen direkt an den Objektspeicher.

Veröffentlicht eine unveränderliche neue Version einer eigenen Anwendung unter Verwendung derselben gebundenen tar.gz-Upload-Pipeline. If-Match schützt die Anwendungsrevision; Annahme erhöht sie, und erfolgreiche Veröffentlichung erhöht sie erneut, wenn sich latest_ready_release ändert. Name und Anwendungsidentität bleiben erhalten. Bestehende Playlist-Release-Pins werden nicht geändert.

Ein identischer idempotenter Wiederholungsversuch gibt die ursprüngliche Operation auch nach Revisionsänderungen zurück. Der Proxy vor der API beendet eine Anfrage, die er nicht innerhalb von etwa 100 s beantwortet hat, sodass ein großes Archiv bei langsamer Uplink-Verbindung hier fehlschlägt; POST /api/applications/{id}/uploads sendet das Archiv stattdessen direkt an den Objektspeicher.

Erklärt einen direkten Upload eines von der CLI erzeugten tar.gz, das eine neue Anwendung erstellt. Die Antwort ist eine signierte Autorisierung für genau einen Objekt-PUT des Archivs, sodass die Bytes direkt an den Objektspeicher gehen und nie durch die API, deren Proxy eine Anfrage beendet, die er nicht innerhalb von etwa 100 s beantwortet hat.

Senden Sie das Archiv per PUT an upload_url, bestätigen Sie dann mit POST /api/applications/uploads/{id}/commit und warten Sie auf die Operation. Die Anwendung, ihre Version und die empfangende Operation existieren ab dieser Antwort, wie nach POST /api/applications. Ein Upload, der nicht innerhalb von 24 Stunden bestätigt wird, schlägt fehl, und eine Anwendung, die nie eine Version veröffentlicht hat, wird entfernt.

Derselbe Idempotency-Key und derselbe Body beantworten denselben Upload mit einer frisch signierten URL. GET /api/capabilities setzt features.application_direct_uploads, wo diese Routen bedient werden.

Erklärt einen direkten Upload einer neuen unveränderlichen Version einer eigenen Anwendung, beantwortet wie POST /api/applications/uploads. If-Match schützt die Anwendungsrevision wie bei POST /api/applications/{id}/releases, und die Annahme erhöht sie. Der Body trägt keinen Namen; eine Version behält den Namen ihrer Anwendung. Bestehende Playlist-Versions-Pins werden nicht geändert.

Bestätigt einen direkten Anwendungs-Upload, sobald dessen PUT abgeschlossen ist. Der Server prüft das bereitgestellte Archiv gegen die Erklärung (seine Größe und die SHA-256-Prüfsumme, die der Objektspeicher mit dem PUT genommen hat), kopiert es in seinen eigenen Upload-Bereitstellungsbereich und reiht die Veröffentlichung ein.

Warten Sie mit GET /api/operations/{id} auf die zurückgegebene Operation, bis sie succeeded oder failed ist, wie nach POST /api/applications. Ein Commit vor Abschluss des PUT antwortet invalid_request und ändert nichts, sodass er erneut gesendet werden kann; bereitgestellte Bytes, die von der Erklärung abweichen, lassen den Upload fehlschlagen. Ein wiederholter Commit antwortet dieselbe Operation.

Ändert den Anzeigenamen einer Anwendung, die dem authentifizierten Projekt gehört. Namen werden getrimmt, enthalten 1 bis 120 Unicode-Zeichen ohne Steuerzeichen und können innerhalb eines Projekts mehrfach vorkommen. Anwendungsidentität, Releases, K/V-Daten und Playlist-Release-Pins bleiben erhalten.

Eine geänderte Bezeichnung erhöht die Anwendungsrevision und löst application.updated aus; dieselbe Bezeichnung ist eine No-Op. If-Match schützt optional die Revision. Ein identischer idempotenter Wiederholungsversuch gibt die ursprüngliche Antwort nach nachfolgenden Metadatenänderungen zurück.

Tombstones eine Anwendung, die dem authentifizierten Projekt gehört, und alle ihre Releases. Der Projektinhaber ist maßgeblich; eine unbekannte oder fremde Projekt-ID ist not_found. If-Match schützt die Anwendungsrevision. Ein Live-Manifest-Verweis blockiert die Löschung mit application_in_use; es gibt keinen Force-Delete-Pfad.