Uszczelnienie uzupełnialnych obiektów blob
Celem Append Blob Seal operacji jest umożliwienie użytkownikom i aplikacjom uszczelnienia uzupełnialnych obiektów blob, oznaczając je jako tylko do odczytu. W tym dokumencie opisano proponowane specyfikacje interfejsu API REST dla tej funkcji.
Żądanie
Żądanie można skonstruować Append Blob Seal w następujący sposób. Zalecane jest użycie protokołu HTTPS. Zastąp wartość myaccount nazwą konta magazynu.
| Identyfikator URI żądania PUT | Wersja PROTOKOŁU HTTP |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal |
HTTP/1.1 |
Nagłówki
Append Blob SealZwraca typowe nagłówki interfejsu API ( ETag/LMT czas ostatniej modyfikacji), x-ms-request-id, x-ms-version, content-lengthi .Date
Append Blob Sealprogram nie zmienia .ETag/LMT
| Nagłówek odpowiedzi | Wartość | Opis |
|---|---|---|
x-ms-blob-sealed |
prawda/fałsz | Opcjonalny. Wartość false domyślnie. Jeśli obiekt blob jest zapieczętowany, ten nagłówek jest dołączany do odpowiedzi podczas zamykania i pobierania właściwości obiektu blob. Ten nagłówek powinien być wyświetlany w GetBlobelementach , GetBlobProperties, AppendBlobSeali ListBlobs dla uzupełnialnych obiektów blob. |
Parametry zapytania
Brak dodatkowych parametrów identyfikatora URI.
Treść żądania
Brak.
Reakcja
Odpowiedź zawiera kod stanu HTTP i listę nagłówków odpowiedzi.
Kod stanu
Możesz otrzymać dowolny z następujących kodów stanu:
200 (Powodzenie): obiekt blob jest zapieczętowany. Wywołanie jest idempotentne i powiedzie się, jeśli obiekt blob jest już zapieczętowany.
409 (InvalidBlobType): usługa zwraca ten kod stanu, jeśli wywołanie znajduje się w istniejącym stronicowym obiekcie blob lub blokowym obiekcie blob.
404 (BlobNotFound): usługa zwraca ten kod stanu, jeśli wywołanie dotyczy nieistniejącego obiektu blob.
Autoryzacja
Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Możesz autoryzować operację Append Blob Seal zgodnie z poniższym opisem.
Ważne
Firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Tożsamość Microsoft Entra zapewnia doskonałe zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza wspólnego.
Usługa Azure Storage obsługuje autoryzację żądań do danych obiektów blob przy użyciu Tożsamość Microsoft Entra. Dzięki Tożsamość Microsoft Entra możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez Tożsamość Microsoft Entra w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.
Aby dowiedzieć się więcej na temat autoryzacji przy użyciu Tożsamość Microsoft Entra, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu Tożsamość Microsoft Entra.
Uprawnienia
Poniżej przedstawiono akcję RBAC niezbędną dla użytkownika Microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Append Blob Seal operacji oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:
- Akcja RBAC platformy Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Najmniej uprzywilejowana wbudowana rola:Współautor danych obiektu blob usługi Storage
Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.
Uwagi
Jeśli obiekt blob dołączania ma dzierżawę, potrzebujesz identyfikatora dzierżawy, aby przypieczętować obiekt blob.
Po uszczelnieniu obiektu blob można nadal aktualizować właściwości, tagi indeksu obiektów blob i metadane. Usuwanie nietrwałe zapieczętowanego obiektu blob zachowuje stan zapieczętowany. Zapieczętowane obiekty blob można zastąpić.
Jeśli wykonasz migawkę zapieczętowanego obiektu blob, migawka zawiera zapieczętowaną flagę. W przypadku istniejących migawek w nowej wersji firma Microsoft zwraca właściwość .
Podczas kopiowania zapieczętowanego obiektu blob flaga zapieczętowana jest domyślnie propagowana. Nagłówek jest ujawniany, który umożliwia zastąpienie flagi.
Do odpowiedzi zostanie dodany ListBlob nowy element XML o nazwie Sealed. Wartością może być true lub false.
Jeśli wywołasz AppendBlock obiekt blob, który jest już zapieczętowany, usługa zwróci komunikat o błędzie przedstawiony w poniższej tabeli. Dotyczy to starszych wersji interfejsu API.
| Kod błędu | Kod stanu HTTP | Komunikat użytkownika |
|---|---|---|
| Obiekt blobIsSealed | Konflikt (409) | Określony obiekt blob jest zapieczętowany, a jego zawartość nie może zostać zmodyfikowana, chyba że obiekt blob zostanie ponownie utworzony po usunięciu. |
Jeśli wywołasz Append Blob Seal dołączany obiekt blob, który został już zapieczętowany, po prostu zobaczysz kod stanu 200 (Powodzenie).
Rozliczenia
Żądania cenowe mogą pochodzić od klientów korzystających z interfejsów API usługi Blob Storage bezpośrednio za pośrednictwem interfejsu API REST usługi Blob Storage lub biblioteki klienta usługi Azure Storage. Te żądania naliczają opłaty za transakcję. Typ transakcji wpływa na sposób naliczania opłat za konto. Na przykład transakcje odczytu są naliczane do innej kategorii rozliczeniowej niż transakcje zapisu. W poniższej tabeli przedstawiono kategorię rozliczeń dla Append Blob Seal żądań na podstawie typu konta magazynu:
| Operacja | Typ konta magazynu | Kategoria rozliczeń |
|---|---|---|
| Uszczelnienie uzupełnialnych obiektów blob | Blokowy obiekt blob w warstwie Premium Standardowa ogólnego przeznaczenia, wersja 2 Standardowa ogólnego przeznaczenia, wersja 1 |
Operacje zapisu |
Aby dowiedzieć się więcej o cenach dla określonej kategorii rozliczeń, zobacz Azure Blob Storage Cennik.