Objektspeicher-APIs
Die wichtigsten Befehle zum Merken
aws s3api list-objects-v2— eine begrenzte Seite von Objektschlüsseln auflisten.aws s3api head-object— Objektmetadaten ohne Nutzdaten herunterladen.
Befehle und Optionen
| Befehl oder Option | Bedeutung |
|---|---|
read -r -p '…' object_bucket |
Bucketnamen erfragen und Backslashes unverändert speichern. |
--bucket "$object_bucket" |
Den eingegebenen Testbucket wählen. |
--prefix lab/ |
Schlüssel mit diesem Anfang auswählen. |
--max-keys 5 --no-paginate |
Höchstens fünf Schlüssel einer Serverseite anfordern, keine Folgeseiten. |
--key lab/hello.txt |
Genau dieses vorhandene Objekt wählen. |
--no-cli-pager |
Direkt ausgeben, ohne Pager. |
Die konfigurierte AWS-Identität signiert die Anfragen. Ein Bucketname ist keine URL. Für die Leseanfragen können normale Anfragekosten des Dienstes anfallen.
Die entscheidenden Konzepte
1. Der Schlüssel ist die Objektadresse
Eine Objekt-API adressiert Daten über Bucket und Schlüssel. lab/hello.txt enthält einen Schrägstrich; dadurch wird lab aber nicht zum gewöhnlichen Dateisystemverzeichnis.
Präfixlisten gruppieren verwandte Schlüssel. Große Listen sind in Seiten aufgeteilt. Eine korrekte Antwort kann deshalb nur einen Teil enthalten. Wer Fortsetzungsinformationen ignoriert, übersieht möglicherweise Daten.
2. Jede API-Operation hat eine eigene Berechtigungsgrenze
Bucket auflisten und Objekt lesen verlangen unterschiedliche Rechte. Eine Identität kann einen bekannten Schlüssel lesen dürfen, ohne den Bucket auflisten zu dürfen. Umgekehrt erlaubt ein sichtbarer Schlüssel nicht zwingend den Download.
Authentifizierung bestimmt den Aufrufer; Richtlinien erlauben die konkrete Aktion auf der Ressource. Eine vorsignierte URL delegiert eine begrenzte Anfrage unter Autorität und Ablaufregeln des Signierers. Ihr Besitz kann auch ohne gewöhnliches Passwort sensibel sein.
3. Metadaten ersetzen nicht den Inhalt
Eine HEAD-Anfrage liefert Metadaten ohne Objektdaten. Größe, Inhaltstyp, Änderungszeit und Entity-Tags unterstützen Entscheidungen zum Abrufen und Vergleichen.
Ein ETag ist nicht allgemein eine MD5-Prüfsumme. Multipart-Uploads und Verschlüsselungsdetails können seine Bedeutung verändern. Für Inhaltsintegrität brauchst du die dokumentierten Prüfsummenfunktionen des Dienstes statt einer pauschalen Hash-Annahme.
4. Konsistenz und Konkurrenz sind verschiedene Fragen
Amazon S3 bietet starke Konsistenz für die dokumentierten Objektzugriffe und Listen. Mehrere getrennte Objektänderungen werden dadurch nicht zu einer Transaktion.
Zwei Schreiber können weiterhin denselben Schlüssel konkurrierend ersetzen. Bedingte Anfragen können unerwartete Versionen ablehnen; Versionierung kann ältere Objektversionen erhalten. Andere S3-kompatible Dienste können andere Garantien besitzen. Ähnliche APIs bedeuten kein identisches Verhalten.
Ein kleines Beispiel
Optional: Nutze dein autorisiertes Testprofil und gib den zugewiesenen Bucketnamen ein. Das Beispiel liest eine kleine Liste und Metadaten des Testobjekts. Es erstellt keine Ressourcen.
read -r -p 'Test bucket: ' object_bucket
aws s3api list-objects-v2 --bucket "$object_bucket" --prefix lab/ --max-keys 5 --no-paginate --no-cli-pager
aws s3api head-object --bucket "$object_bucket" --key lab/hello.txt --no-cli-pager
Prüfe Key und Size in Bytes. IsTruncated: true weist auf weitere Ergebnisse außerhalb dieser begrenzten Seite hin. Vergleiche bei HEAD gegebenenfalls ContentLength, ContentType und ETag.
Ein HEAD-Fehler unterscheidet fehlendes Objekt und fehlende Rechte nicht immer eindeutig: S3 kann abhängig vom Listrecht unterschiedliche Statuscodes liefern. Erfolgreiches HEAD belegt Metadatenzugriff, keinen vollständigen Download oder sicheren Schreibwettbewerb. Aufräumen entfällt.
Merke dir: Objekt-APIs arbeiten mit Schlüsseln und einzelnen Anfragen. Ordnerdarstellung schafft weder Dateisystem- noch Transaktionssemantik.