Uploads und Frontend-Integration # Leitfaden zur File Upload API: Architektur, Sicherheit und Anbieterauswahl Eine File Upload API anhand von Architektur, Wiederaufnahme, direkter Cloud-Übertragung, Sicherheit, Speichergrenzen und Anbietern auswählen und implementieren. Veröffentlicht am 24. August 2026 ## Wichtigste Erkenntnisse * Benennen Sie den Bytepfad explizit: Weiterleitung durch die Anwendung, direkter Objektspeicher, direkter Verarbeitungsdienst oder Import aus einer Remote-Quelle. * Behandeln Sie fortsetzbare Uploads, vollständige Wiederholungsversuche, Idempotenz und Ablaufzeiten als separate Zuverlässigkeitsmechanismen mit unterschiedlichem Fehlerverhalten. * Belassen Sie die Upload-Autorisierung auf dem Server, validieren Sie die ermittelten Dateieigenschaften und veröffentlichen Sie ausschließlich aus einem kontrollierten dauerhaften Speicher. Die Wahl einer Datei-Upload-API ist eine Architekturentscheidung, kein Vergleich von Widgets. Das richtige Design steuert, wohin Bytes übertragen werden, wer eine Übertragung autorisieren darf, wie unterbrochene Vorgänge fortgesetzt werden, wann eine Datei als vertrauenswürdig gilt, wo dauerhafte Kopien gespeichert sind und wie Verarbeitungsergebnisse an das Produkt zurückgegeben werden. ## In diesem Leitfaden 1. [Den Upload-Auftrag vor der Auswahl eines Widgets definieren](#file-upload-api-guide-section-1) 2. [Einen von vier expliziten Byte-Pfaden auswählen](#file-upload-api-guide-section-2) 3. [Wiederaufnahme getrennt von Wiederholungsversuchen konzipieren](#file-upload-api-guide-section-3) 4. [Die Absicht serverseitig autorisieren und den Bytes misstrauen](#file-upload-api-guide-section-4) 5. [Dauerhaften Speicher von der Upload-Verarbeitung trennen](#file-upload-api-guide-section-5) 6. [An der Eigentumsgrenze zwischen Eigenentwicklung und Zukauf entscheiden](#file-upload-api-guide-section-6) 7. [Anbieter mit Fehlertests statt anhand der Funktionsanzahl vergleichen](#file-upload-api-guide-section-7) 8. [Einen signierten Upload mit Uppy und Transloadit implementieren](#file-upload-api-guide-section-8) 9. [Annahme, Validierung, Verarbeitung und Export verbinden](#file-upload-api-guide-section-9) ## Worauf es besonders ankommt * Entscheiden Sie sich für Eigenentwicklung, Zukauf oder ein hybrides Betriebsmodell, indem Sie die Anforderungen an Wiederherstellung, Sicherheit, Verarbeitung und Betrieb testen, nicht nur die Demo für den Idealfall. * Verwenden Sie frameworkspezifische Beispiele nur, wenn deren Lebenszyklus, Serverautorisierung und Wiederherstellungsverhalten gewartet und getestet werden können. ## Den Upload-Auftrag vor der Auswahl eines Widgets definieren Ein produktiver Upload beginnt, bevor das erste Byte übertragen wird. Die Anwendung identifiziert den Nutzer, entscheidet, welcher Vorgang zulässig ist, legt die erlaubte Anzahl und Größe der Dateien fest und erstellt einen Datensatz, der länger als ein Browser-Tab bestehen kann. Die Übertragung ist nur eine Phase. Validierung, Verarbeitung, Export, Benachrichtigung und Abgleich bestimmen, ob das Produkt die Datei anschließend sicher verwenden kann. Formulieren Sie einen Abschlussvertrag aus Produktsicht. „Die Anfrage gab 200 zurück“ ist wenig aussagekräftig; „Das Original und die erforderlichen Derivate sind unter diesem Mandanten gespeichert, der Asset-Datensatz nennt ihre Versionen und ein doppelter Callback ändert nichts“ ist testbar. Halten Sie fest, bei welchen Fehlern Nutzer einen erneuten Versuch starten dürfen, welche einen neuen Upload erfordern und welche einen für den Operator sichtbaren Zustand zur Wiederherstellung hinterlassen. ### Steuerungsebene Überträgt Identität, Autorisierung, Limits, Workflow-Auswahl, Metadaten, Status und Ergebnisreferenzen, nicht den Dateiinhalt selbst. ### Datenebene Überträgt Dateibytes zwischen Nutzer, Anwendung, Upload-Dienst, Verarbeitungsebene und dauerhaftem Speicherziel. ### Vertrauensübergang Kennzeichnet, wann ein nicht vertrauenswürdiger Upload die für Verarbeitung, Speicherung, Vorschau oder öffentliche Auslieferung erforderlichen Prüfungen bestanden hat. ## Einen von vier expliziten Byte-Pfaden auswählen Bei einer Weiterleitung über die Anwendung sendet der Browser die Datei an Ihren Server, der sie weiterleitet oder speichert. Das ist nachvollziehbar und gibt der Anwendung unmittelbare Kontrolle, doch jedes Byte beansprucht eingehende Bandbreite, Arbeitsspeicher oder temporären Festplattenspeicher, Verbindungszeit und ausgehende Bandbreite. Dieses Modell eignet sich für kleine, selten übertragene Dateien, wenn der vorhandene Server Limits durchsetzen und Daten sicher streamen kann, ohne vollständige Inhalte zwischenzuspeichern. „Direkt in die Cloud“ ist mehrdeutig, benennen Sie daher das Ziel. Ein Browser kann mit kurzlebigen Zugangsdaten direkt in einen Objektspeicher oder direkt zu einem Verarbeitungsdienst wie Transloadit hochladen. Alternativ kann er einen Dienst anweisen, eine vorhandene Remote-URL zu importieren. Die direkte Speicherung minimiert Übertragungsstationen, wenn die dauerhafte Speicherung die einzige Aufgabe ist. Bei der direkten Verarbeitung bleibt die Anwendung außerhalb des Datenpfads, während ein Workflow Dateien validiert, transformiert und in einen eigenen Speicher exportiert. ### Weiterleitung über die Anwendung Geeignet für überschaubare Workloads und einfache Richtlinien, doch die Anwendung ist für Übertragungskapazität, Zeitüberschreitungen, temporäre Dateien und Skalierung verantwortlich. ### Direkte Objektspeicherung Optimal, wenn die erste dauerhaft gespeicherte Kopie das Hauptergebnis ist und die spätere Verarbeitung zuverlässig durch ein Speicherereignis oder eine Warteschlange ausgelöst werden kann. ### Direkter Verarbeitungsdienst Geeignet, wenn Upload und asynchrone Validierung, Derivate, Metadaten oder der Export an mehrere Ziele zu einem einzigen beobachtbaren Verarbeitungsvorgang gehören. ### Import aus Remote-Quellen Überträgt Bytes von Server zu Server. Das schont die Verbindung des Nutzers, erfordert jedoch eine explizite Autorisierung der Quelle und Abruflimits. ## Wiederaufnahme getrennt von Wiederholungsversuchen konzipieren Ein Wiederholungsversuch startet einen Vorgang erneut; eine fortsetzbare Übertragung setzt dagegen einen bestehenden Upload ab einem vom Server bestätigten Byte-Offset fort. Bei tus behält der Client die Upload-URL, fragt den Server nach `Upload-Offset` und sendet nur die verbleibenden Bytes. Speichern Sie diese URL außerhalb des flüchtigen Komponentenzustands, wenn nach einem Neuladen oder Absturz eine Wiederherstellung möglich sein soll. Erstellen Sie zudem sorgfältig Fingerprints der Dateien, damit die lokale Datei eines Nutzers niemals der Upload-Ressource eines anderen zugeordnet wird. Fortsetzbare Uploads bedeuten weder unbegrenzte Zeit noch eine idempotente Verarbeitung. Eine Transloadit Assembly hat ab ihrer Erstellung weiterhin acht Stunden Zeit, um den Upload abzuschließen. Das Erstellen einer Ersatz-Assembly kann Arbeit duplizieren, sofern die Anwendung die alte Kennung nicht abgleicht. Legen Sie fest, wie der Client mit Pausen, Offline-Zeiten, abgelaufenen Ressourcen, geänderten Dateien, abgebrochenen Uploads und einer verlorenen Abschlussantwort umgeht, nachdem der Server die letzten Bytes akzeptiert hat. ### Identität für die Fortsetzung Speichern Sie die vom Server ausgegebene Upload-URL zusammen mit dem authentifizierten Nutzer, dem Fingerprint der lokalen Datei, der erwarteten Länge und dem Vorgangsdatensatz dauerhaft. ### Ablaufpfad Wenn die Upload-Ressource oder Assembly abgelaufen ist, erstellen Sie einen neuen Vorgang und mustern Sie die veraltete Kennung aus, statt es unbegrenzt erneut zu versuchen. ### Abgleich des Abschlusses Fragen Sie nach mehrdeutigen Netzwerkfehlern den dauerhaft gespeicherten Status ab, damit der Client aus einer fehlenden Antwort nicht auf fehlende Bytes schließt. ## Die Absicht serverseitig autorisieren und den Bytes misstrauen Ein öffentlicher Auth Key darf im Browsercode enthalten sein, das Auth Secret von Transloadit oder dauerhafte Zugangsdaten für den Speicher jedoch niemals. Authentifizieren Sie den Nutzer in Ihrer Anwendung, wählen Sie serverseitig ein gespeichertes Template aus und geben Sie kurzlebige signierte Parameter mit einer eindeutigen `nonce` zurück. Setzen Sie `allow_steps_override` auf false, wenn es keinen legitimen Grund dafür gibt, dass der Browser Steps ersetzt, da ein vom Client ausgewählter Step-Graph andernfalls die Verarbeitung oder das Exportverhalten ändern könnte. Eine gültige Signatur belegt, dass die Parameter-Nutzlast autorisiert wurde. Sie belegt nicht, dass die hochgeladenen Bytes mit einem Dateinamen, einer Dateiendung, einem deklarierten MIME-Typ, einem Mandanten oder einer Moderationsrichtlinie übereinstimmen. Begrenzen Sie Anfrageinhalte vor rechenintensiven Arbeiten, untersuchen Sie die ermittelten Dateieigenschaften, lehnen Sie nicht unterstützte Inhalte ab und führen Sie Scans durch, wenn das Bedrohungsmodell dies erfordert. Halten Sie außerdem nicht vertrauenswürdige Ausgaben von öffentlichen Speichern fern, bis der Workflow einen genehmigten Zustand erreicht. ### Kurzlebige Autorisierung Erteilen Sie die Upload-Berechtigung erst nach der Authentifizierung durch die Anwendung, beschränken Sie sie zeitlich und begrenzen Sie ihren Umfang auf einen serverseitig ausgewählten Vorgang. ### Ermittelte Eigenschaften Verwenden Sie den erkannten Typ, die Abmessungen, die Dauer und weitere untersuchte Metadaten für die Weiterleitung, statt allein der Dateiendung zu vertrauen. ### Quarantäne vor Veröffentlichung Trennen Sie den Empfang von der öffentlichen Auslieferung, damit ungültige, schädliche oder aufgrund von Richtlinien abgelehnte Dateien nicht standardmäßig zu Assets der Anwendung werden. ## Dauerhaften Speicher von der Upload-Verarbeitung trennen Ein Upload-Endpunkt ist nicht automatisch ein führendes System. Legen Sie fest, welchem Bucket oder welcher Asset-Datenbank das Original zugeordnet ist, wie Derivate damit verknüpft sind, welche Kennungen Umbenennungen überdauern und wer jede Kopie löscht. Wenn eine Transloadit Assembly keinen Export-Step enthält, werden temporäre Dateien nach 24 Stunden gelöscht, und ihre Zugriffs-URLs können nach wenigen Stunden ablaufen. Die URLs sind nur für den kurzfristigen Abruf vorgesehen, nicht für das Einbetten oder die wiederholte Auslieferung im Produkt. Integrieren Sie den Export in die Assembly, wenn der Workflow nur bei erfolgreicher Verarbeitung und dauerhafter Speicherung als erfolgreich gilt. Ein Export-Robot kann gespeicherte Template-Zugangsdaten verwenden, um Ergebnisse im Rahmen des Workflows an das ausgewählte Ziel zu schreiben. Alternativ können Sie Dateien zunächst direkt in einen eigenen Speicher hochladen und die Verarbeitung durch ein kontrolliertes Ereignis auslösen. Dieser Pfad erzeugt frühzeitig eine dauerhafte Kopie, erfordert jedoch zusätzliche Orchestrierung und eine weitere Übertragung an den Verarbeitungsdienst. ### Zuständigkeit für das Original Legen Sie fest, ob und wie lange das Original aufbewahrt wird, unter welchem Mandantenschlüssel dies geschieht und ob spätere Workflows erneut darauf zugreifen dürfen. ### Abstammung der Derivate Speichern Sie die Quellkennung, die Workflow-Konfiguration, die Rolle der Ausgabe, die Abmessungen, das Format und die Prüfsumme, die zur Nachvollziehbarkeit jedes Ergebnisses erforderlich sind. ### Auslieferungsgrenze Liefern Sie genehmigte Assets aus dauerhaftem Speicher und über eine bewusst gewählte Auslieferungsschicht statt über temporäre Verarbeitungs-URLs aus. ## An der Eigentumsgrenze zwischen Eigenentwicklung und Zukauf entscheiden Entwickeln Sie den Übertragungspfad selbst, wenn die Anforderungen eng begrenzt sind und das Team bereit ist, den gesamten Lebenszyklus zu verantworten. Ein kleines authentifiziertes Formular, das kurze Dateien per Streaming in einen bestehenden Bucket überträgt, rechtfertigt möglicherweise keine weitere Plattform. Die Schätzung muss dennoch Multipart-Parsing, Backpressure, die Durchsetzung von Größenlimits, fortsetzbare Uploads oder deren bewussten Verzicht, Bereinigung, Schutz vor Missbrauch, Beobachtbarkeit, Upgrades und die Behandlung von Fehlern außerhalb der Lebensdauer der Anfrage berücksichtigen. Ein verwalteter Dienst wird attraktiver, wenn der Workflow unzuverlässige Netzwerke, große Dateien, Browser-UX, Remote-Quellen, Medienprüfung, Transformation oder mehrere Speicherziele kombiniert. Der Zukauf entbindet Sie nicht von der Verantwortung für Ihre Anwendung: Mandantenprüfungen, Autorisierung, Asset-Datensätze, Aufbewahrung, Veröffentlichung und Vorfallbehandlung bleiben in Ihrer Hand. Oft eignet sich eine hybride Architektur am besten, bei der eigener Speicher und der Geschäftszustand eine verwaltete Übertragungs- und Verarbeitungsebene umgeben. ### Kosten der Eigenentwicklung Berücksichtigen Sie Entwicklung, Infrastruktur, Bereitschaftsdienst, Protokollwartung, Sicherheitsprüfungen und Nutzersupport, nicht nur die Gebühren für Objektspeicher. ### Kosten des Zukaufs Modellieren Sie Upload-Bytes, Verarbeitungsvorgänge, Wiederholungsversuche, Speicherübertragungen, Mindestgebühren, Supportniveau und erwartetes Wachstum. ### Hybride Zuständigkeit Behalten Sie Identität, Richtlinien, Metadaten und dauerhaften Speicher in Ihrem Produkt, während Sie den spezialisierten Datenpfad und die Verarbeitung delegieren. ## Anbieter mit Fehlertests statt anhand der Funktionsanzahl vergleichen Erstellen Sie eine Bewertungsmatrix anhand der tatsächlichen Auslastung Ihres Produkts. Vergleichen Sie Browser- und mobile Clients, die Unterstützung offener Protokolle, die maximale Dateigröße, das Verhalten bei parallelen Vorgängen, geografische Endpunkte, Remote-Importe, den Verarbeitungsumfang, Speicherziele, die Isolierung von Zugangsdaten, die Webhook-Verifizierung, die Aufbewahrung von Statusdaten, den Support und Ausstiegsoptionen. Kennzeichnen Sie jede Funktion als erforderlich, optional oder irrelevant, bevor Sie sich Anbieterseiten ansehen. Testen Sie jeden ernst zu nehmenden Kandidaten mit denselben Testdaten. Unterbrechen Sie einen großen Upload, laden Sie die Seite neu, senden Sie ein doppeltes Abschlussereignis, widerrufen Sie Speicherzugangsdaten, lehnen Sie eine Datei nach dem Empfang ab, überschreiten Sie einen Grenzwert und lassen Sie die abschließende Antwort verloren gehen. Messen Sie die für Nutzer sichtbare Wiederherstellung, erneut übertragene Bytes, die Zeit bis zu einem dauerhaft gespeicherten Ergebnis, Nachweise für den Betrieb und die Bereinigung. Eine ausgereifte Dateiauswahl sagt wenig darüber aus, wie sich das System unter echten Produktionsbedingungen verhält. ### Protokollportabilität Ein offenes Protokoll für fortsetzbare Uploads und austauschbare Clients verringern die Migrationskopplung, doch Workflow- und Ergebnisschemata erfordern weiterhin eine Migrationsplanung. ### Betriebliche Nachweise Fordern Sie stabile Auftragskennungen, Endzustände, Zeitstempel, verwertbare Fehlermeldungen, verifizierte Callbacks und ein dokumentiertes Verfahren zur erneuten Ausführung. ### Gesamtwirtschaftlichkeit Vergleichen Sie bei einem repräsentativen monatlichen Volumen die Kosten für Übertragung, Verarbeitung, Speicher, Auslieferung, Support, Entwicklung und Wiederherstellung nach Fehlern. ## Einen signierten Upload mit Uppy und Transloadit implementieren Im Browserbeispiel übernimmt Uppy die Dateiauswahl und die tus-Übertragung, während das Transloadit-Plugin Assembly-Parameter von Ihrer Anwendung anfordert. Der Serverendpunkt muss den aktuellen Nutzer authentifizieren, bevor er das Objekt aus `calcSignature` zurückgibt. Er sollte das Template selbst auswählen, statt beliebige Steps oder ein vom Aufrufer vorgegebenes Speicherziel zu akzeptieren, und er sollte die Anfragerate für Autorisierungen unabhängig vom Upload-Datenverkehr begrenzen. Der Auth Key identifiziert den Workspace und kann in den zurückgegebenen Parametern enthalten sein; das Auth Secret verbleibt im Serverprozess. Deaktivieren Sie im gespeicherten Template Step-Überschreibungen, sofern sie nicht für einen geprüften Anwendungsfall erforderlich sind. Legen Sie fest, ob die Benutzeroberfläche auf das Encoding wartet oder nach dem Upload zurückkehrt. Speichern Sie die Assembly ID in beiden Fällen, damit ein Hintergrundprozess oder ein verifizierter Webhook das Endergebnis abgleichen kann. Uppy begrenzte Assembly-Parameter vom eigenen Backend anfordern lassen ``` import Uppy from '@uppy/core' import Transloadit from '@uppy/transloadit' const uppy = new Uppy().use(Transloadit, { async assemblyOptions() { const response = await fetch('/api/transloadit-params', { credentials: 'same-origin', }) if (!response.ok) { throw new Error('Could not authorize this upload') } return response.json() }, waitForEncoding: true, }) uppy.on('transloadit:complete', (assembly) => { console.log(assembly.assembly_id, assembly.results) }) ``` Ein serverseitig ausgewähltes Template signieren, ohne das Auth Secret offenzulegen ``` import { randomUUID } from 'node:crypto' import { Transloadit } from 'transloadit' function requiredEnvironmentValue(name: string): string { const value = process.env[name] if (value == null) throw new Error(`Missing environment variable: ${name}`) return value } const transloadit = new Transloadit({ authKey: requiredEnvironmentValue('TRANSLOADIT_KEY'), authSecret: requiredEnvironmentValue('TRANSLOADIT_SECRET'), }) export function createAuthorizedUploadParameters() { // Call this only after the server has authenticated the request and authorized the operation. return transloadit.calcSignature({ auth: { expires: new Date(Date.now() + 5 * 60 * 1000).toISOString(), nonce: randomUUID(), }, template_id: requiredEnvironmentValue('TRANSLOADIT_UPLOAD_TEMPLATE_ID'), }) } ``` ## Annahme, Validierung, Verarbeitung und Export verbinden Das Template nimmt Browser-Uploads über `/upload/handle` an, prüft die erkannte MIME-Familie mit `/file/filter`, erstellt über `/image/resize` eine begrenzte Vorschau und exportiert mit `/s3/store` sowohl das akzeptierte Original als auch die Vorschau. Mit den benannten Template-Zugangsdaten bleiben die Bucket-Zugangsdaten aus den Browserparametern heraus, während `allow_steps_override` verhindert, dass ein Aufrufer dieses Ziel durch eine Step-Überschreibung ersetzt. Betrachten Sie dies als minimales Architekturbeispiel und nicht als allgemeingültige Sicherheitsrichtlinie. Ergänzen Sie gemäß dem Bedrohungsmodell des Produkts Regeln für die maximale Upload-Größe, die Dateianzahl, Virenprüfungen, Moderation, Benennung, Aufbewahrung und Ziele. Speichern Sie die Assembly ID und die Datensätze der exportierten Ergebnisse unter dem authentifizierten Mandanten. Prüfen Sie außerdem, ob jede erwartete Ausgabe den dauerhaften Speicher erreicht hat, bevor die Anwendung das Asset als bereit markiert. Dateien mit einem gesperrten Template validieren, ableiten und exportieren ``` { "allow_steps_override": false, "steps": { ":original": { "robot": "/upload/handle" }, "accepted_images": { "use": ":original", "robot": "/file/filter", "accepts": [ ["${file.mime}", "regex", "^image/"] ], "error_on_decline": true }, "preview": { "use": "accepted_images", "robot": "/image/resize", "resize_strategy": "fit", "width": 1600, "height": 1600 }, "exported": { "use": ["accepted_images", "preview"], "robot": "/s3/store", "credentials": "my_s3_credentials", "path": "uploads/${file.id}/${file.url_name}" } } } ``` ## Wissenswerte technische Details * Bei einem Upload vom Browser an die Anwendung wird der Anwendungsserver Teil des Datenpfads. Ein Konzept mit direkter Speicherung oder direkter Verarbeitung hält die Dateibytes dagegen aus diesem Request-Handler heraus. * Das tus-Kernprotokoll setzt einen unterbrochenen Upload fort, indem es den serverseitigen `Upload-Offset` mit `HEAD` ausliest und mit `PATCH` weiterüberträgt; die gesamte Datei erneut zu senden ist ein Wiederholungsversuch, keine Wiederaufnahme. * Das Transloadit-Plugin von Uppy verwendet tus für die Dateiübertragung und kann mithilfe seiner Funktion `assemblyOptions` signierte Assembly-Parameter von einem Anwendungs-Backend anfordern. * Transloadit Signature Authentication signiert die JSON-codierten Parameter auf einem vertrauenswürdigen Server mit dem Auth Secret; das Geheimnis selbst darf niemals an Browsercode gesendet werden. * Ein gespeichertes Template, bei dem `allow_steps_override` auf false gesetzt ist, verhindert, dass ein nicht vertrauenswürdiger Client die zugehörigen Steps ersetzt oder durch Überschreibungen von Steps ein anderes Speicherziel auswählt. * Ohne Export-Robot löscht Transloadit temporäre Dateien nach 24 Stunden. Ihre temporären URLs können bereits nach wenigen Stunden ablaufen und sind nur für einen begrenzten, kurzfristigen Abruf vorgesehen. * Bei tus-Uploads an Transloadit wird die Assembly erstellt, bevor die Dateibytes eintreffen, und verbleibt in `ASSEMBLY_UPLOADING`, bis die deklarierten Uploads abgeschlossen sind. * Das Zeitfenster für Uploads bei Transloadit beträgt ab der Erstellung der Assembly acht Stunden. Daher benötigt auch ein Client für fortsetzbare Uploads einen ausdrücklich vorgesehenen Ablauf für einen Neustart, wenn die Assembly abgelaufen ist. ## Ein praxisnaher Ansatz 1. 1\ Dokumentieren Sie den Bytepfad, die Vertrauensübergänge, den dauerhaften Eigentümer und den Abschlussvertrag, bevor Sie einen Dateiuploader auswählen. 2. 2\ Testen Sie Optionen für die Weiterleitung, den direkten Speicher und die direkte Verarbeitung mit repräsentativen Dateien und Netzwerkausfällen. 3. 3\ Implementieren Sie kurzlebige serverseitige Autorisierung, fortsetzbare Uploads, Validierung, Export und eine idempotente Ergebnisverarbeitung. 4. 4\ Führen Sie Lasttests für den gewählten Pfad durch und proben Sie abgelaufene Autorisierungen, doppelte Callbacks, widerrufene Zugangsdaten und Teilausfälle. Ein vierstufiger Medienworkflow ## Wann Transloadit hilfreich ist Verwenden Sie Transloadit, wenn Uploads mit tus fortsetzbar sein müssen oder wenn Sie die Browser-UX von Uppy, den Import aus Remote-Quellen, eine mehrstufige Dateiverarbeitung oder Exporte in von Ihnen kontrollierten Speicher benötigen. Die genauen Parameterverträge finden Sie in der Robot-Dokumentation zu `/upload/handle`, `/file/filter`, `/image/resize` und `/s3/store`. ## Architekturgrenze Transloadit kann Dateien empfangen, asynchrone Verarbeitungsworkflows ausführen und Ergebnisse exportieren. Ihre Anwendung bleibt jedoch für die Nutzerauthentifizierung, die Mandantenautorisierung, den dauerhaft gespeicherten Datensatz des Assets, die Veröffentlichungsrichtlinie und die Auslieferung aus dem permanenten Speicher verantwortlich. ## Häufig gestellte Fragen ### Was bedeutet „direkter Cloud-Upload“? Damit ist nicht nur eine Architektur gemeint. Es kann sich um eine Übertragung vom Browser in den Objektspeicher, vom Browser an einen Verarbeitungsdienst oder um einen Server-zu-Server-Import von einem anderen Anbieter handeln. Benennen Sie das tatsächliche Ziel der Bytes, den Autorisierungsmechanismus, den dauerhaften Eigentümer und den Verarbeitungsauslöser, bevor Sie Implementierungen vergleichen. ### Sollten Dateien meinen Anwendungsserver durchlaufen? Nur wenn der Vorteil für Richtlinien oder Einfachheit die Verantwortung für den Datenpfad überwiegt. Das Weiterleiten kann sich für kleine, seltene Uploads eignen. Bei der direkten Speicherung oder Verarbeitung werden jedoch nicht für jedes Byte Anwendungsbandbreite, Anfragezeit, temporärer Speicherplatz und Verbindungskapazität beansprucht. ### Ist ein Wiederholungsversuch dasselbe wie ein fortsetzbarer Upload? Nein. Ein Wiederholungsversuch startet die Übertragung normalerweise erneut, während bei der Wiederaufnahme eine vorhandene Ressource ab dem vom Server bestätigten Byte-Offset fortgesetzt wird. Der Client muss die Upload-Identität beibehalten und weiterhin mit Ablaufzeiten, geänderten lokalen Dateien und mehrdeutigen abschließenden Antworten umgehen. ### Speichert Transloadit hochgeladene Dateien dauerhaft? Nein, es sei denn, der Workflow exportiert sie an ein dauerhaftes Ziel. Ohne Export-Robot werden temporäre Dateien nach 24 Stunden gelöscht, und ihre URLs können nach wenigen Stunden ablaufen. Produktiv-Workflows sollten die Dateien in einen kontrollierten Speicher exportieren oder diese URLs nur verwenden, um sie kurzfristig und in begrenztem Umfang in die eigene Infrastruktur abzurufen. ### Wann sollte ich eine Upload-API selbst entwickeln, statt sie zu kaufen? Eine Eigenentwicklung kann für einen eng begrenzten Pfad mit kleinen Dateien, einem Speicherziel, vorhersehbaren Netzwerken und einem Team sinnvoll sein, das Sicherheit und Betrieb vollständig verantworten kann. Verwaltete Infrastruktur rechtfertigt ihre Kosten, wenn fortsetzbare Uploads, Remote-Quellen, große Dateien, Verarbeitung, mehrere Ziele oder die Wiederherstellung nach Fehlern sonst zu einem eigenen Produkt würden. ### Was gehört in einen frameworkspezifischen Upload-Leitfaden? Ein Framework-Leitfaden sollte sich auf wartbaren Code, das Lebenszyklusverhalten, die serverseitige Autorisierung, die Wiederherstellung und Tests für dieses Framework konzentrieren. Die verlinkten Referenzen zur Wiederaufnahme und API enthalten die genauen Protokoll- und Anfrageverträge. Bewerten Sie Anbieter anhand der weiter oben beschriebenen umfassenderen Architekturanforderungen. ## Erstellen Sie den Workflow Entwickeln Sie das Konzept mithilfe der Robot-Dokumentation und funktionsfähiger Demos zu einer getesteten Assembly weiter. ### Relevante Robots * [/upload/handle](/de/docs/robots/upload-handle.md) * [/file/filter](/de/docs/robots/file-filter.md) * [/image/resize](/de/docs/robots/image-resize.md) * [/s3/store](/de/docs/robots/s3-store.md) * [Verwaltete Datei-Uploads entdecken](/de/services/handling-uploads.md) * [API-Referenz für fortsetzbare Uploads lesen](/de/docs/api/resumable-uploads.md) * [Referenz zu Signature Authentication lesen](/de/docs/api/authentication.md) * [Lesen Sie die API-Dokumentation](/de/docs.md) * [Entdecken Sie funktionsfähige Demos EN (English)](/demos.md) * [Kostenlosen Workspace erstellen](/c/signup/) Uploads und Frontend-Integration ## Mit verwandten Leitfäden fortfahren * [Große Uploads trotz Verbindungsabbruch zuverlässig annehmen](/de/guides/resumable-uploads-for-large-files.md)\ Nehmen Sie Multi-Gigabyte-Uploads über tus an, setzen Sie sie nach Verbindungsabbrüchen fort und halten Sie die Assembly bis zum Abschluss aktiv. * [Medienautomatisierung: vom Upload zur zuverlässigen Ausgabe](/de/guides/media-automation.md)\ Automatisieren Sie wiederholbare Medienaufnahme, Transformation, Validierung und Export, ohne Beobachtbarkeit und Kontrolle einzuschränken. * [Sichere Datei-Uploads in Next.js mit Uppy und signierten Transloadit Templates](/de/guides/secure-file-uploads-nextjs-uppy.md)\ Sicherer Next.js-App-Router-Upload mit Uppy, Serversignierung, gesperrtem Template, verbindlicher Prüfung, fortsetzbarem Transfer und asynchronem Abschluss. * [Die besten JavaScript-Bibliotheken für Datei-Uploads: Uppy vs. FilePond vs. Dropzone](/de/guides/best-javascript-file-upload-libraries.md)\ Vergleichen Sie Uppy, FilePond und Dropzone nach Protokoll, Schnittstellenmodell, Wiederherstellung, Integration und langfristiger Verantwortung. * [React-Datei-Uploads mit Uppy: fortsetzbare Uploads, Vorschauen, Validierung und Verarbeitung](/de/guides/react-file-uploads-with-uppy.md)\ React-Dateiuploader mit Uppy bauen: Vorschau, Validierung, barrierefreier Fortschritt, Abbruch, fortsetzbarer Upload und Übergabe zur Transloadit-Verarbeitung.