HTTP-Dictionary-ID-Header

Typ

Der Dictionary-ID-Header ist ein HTTP-Request- und Response-Header, mit dem Client und Server gemeinsame Kompressionswörterbücher referenzieren und wiederverwendbare Kompression ermöglichen.

Syntax

Der Header enthält einen Hash-Wert, der ein spezifisches Kompressionswörterbuch identifiziert.

http 
Dictionary-ID: :abc123xyz789==:
Dictionary-ID: :sha256-47DEQpj8HBSa+/TImW+5JCeuQeR:

Direktiven

Der Dictionary-ID-Header verwendet einen Dictionary-Identifier:

dictionary-hash
Ein Base64-kodierter Hash des Kompressionswörterbuchs. Ermöglicht eindeutige Identifikation ohne Übertragung des kompletten Dictionaries.
request-header
Client sendet Dictionary-ID im Request, um anzuzeigen, welches Dictionary er für die Dekompression der Response verwenden kann.
response-header
Server sendet Dictionary-ID im Response, um anzuzeigen, welches Dictionary zur Kompression verwendet wurde.

Beispiele

API nutzt Shared Dictionary für wiederkehrende JSON-Strukturen

Ein Client lädt ein API-Kompressionswörterbuch:

http 
GET /api/v1/dictionaries/products-v1 HTTP/1.1
Host: api.example.com

Der Server liefert das Dictionary:

http 
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Cache-Control: public, max-age=31536000, immutable
ETag: "dict-v1-abc123"

[Binäres Kompressionswörterbuch mit häufigen JSON-Keys]

Client verwendet Dictionary für API-Request:

http 
GET /api/v1/products?limit=100 HTTP/1.1
Host: api.example.com
Dictionary-ID: :abc123xyz789==:
Accept-Encoding: br, gzip

Server komprimiert Response mit dem Dictionary:

http 
HTTP/1.1 200 OK
Dictionary-ID: :abc123xyz789==:
Content-Encoding: br-d
Vary: Accept-Encoding, Dictionary-ID
Content-Type: application/json

[Hochkomprimierte JSON-Daten unter Verwendung des Dictionaries]

Versioniertes Dictionary für API-Schema-Updates

Eine API aktualisiert ihr Kompressionswörterbuch mit neuer Schema-Version:

http 
GET /api/v2/orders HTTP/1.1
Host: api.example.com
Dictionary-ID: :old_dict_v1==:
Accept-Encoding: br-d

Der Server erkennt veraltetes Dictionary und liefert unkomprimiert:

http 
HTTP/1.1 200 OK
Available-Dictionary: /api/v1/dictionaries/orders-v2
Content-Type: application/json

{
  "message": "Please fetch updated dictionary for optimal compression"
}

Client lädt neues Dictionary und wiederholt Request:

http 
GET /api/v2/orders HTTP/1.1
Host: api.example.com
Dictionary-ID: :new_dict_v2==:
Accept-Encoding: br-d

GraphQL-API mit Schema-basiertem Dictionary

Eine GraphQL-API nutzt Schema-basierte Kompression:

http 
POST /graphql HTTP/1.1
Host: api.example.com
Dictionary-ID: :graphql_schema_abc==:
Content-Type: application/json
Content-Encoding: br-d

[Komprimierte GraphQL-Query mit Dictionary]

Der Server dekomprimiert und antwortet mit gleichem Dictionary:

http 
HTTP/1.1 200 OK
Dictionary-ID: :graphql_schema_abc==:
Content-Encoding: br-d
Content-Type: application/json

[Komprimierte GraphQL-Response]

Shared-Dictionary-Compression-Flow

Der Ablauf der Shared-Dictionary-Compression für API-Kommunikation.

plantuml 
@startuml
actor Client
participant "API Gateway" as Gateway
database "Dictionary Store" as DictStore
participant "API Service" as API

Client -> Gateway: GET /api/v1/products\n(first visit)
Gateway --> Client: 200 OK\nAvailable-Dictionary: /dicts/products-v1\n[uncompressed response]

Client -> Gateway: GET /dicts/products-v1
Gateway -> DictStore: Fetch dictionary
DictStore --> Gateway: Dictionary binary
Gateway --> Client: 200 OK\nCache-Control: immutable\n[dictionary ~50KB]

Client -> Client: Store dictionary\nCompute hash: abc123

Client -> Gateway: GET /api/v1/products\nDictionary-ID: :abc123==:\nAccept-Encoding: br-d
Gateway -> Gateway: Verify dictionary\nin cache
Gateway -> API: Get products data
API --> Gateway: JSON response (200KB)
Gateway -> Gateway: Compress with\ndictionary abc123\n(output: 30KB)
Gateway --> Client: 200 OK\nDictionary-ID: :abc123==:\nContent-Encoding: br-d\n[compressed 30KB]

note right
85% size reduction using
shared dictionary containing
common JSON structures
end note
@enduml

Vorteile für die Systemarchitektur

  • Reduziert Bandbreite drastisch durch wiederverwendbare Kompressionswörterbücher
  • Besonders effektiv für APIs mit wiederkehrenden JSON-Strukturen und Feldnamen
  • Dictionary wird nur einmal übertragen und für viele Requests wiederverwendet
  • Versionierung erlaubt nahtlose Updates ohne Breaking Changes
  • Kombinierbar mit Standard-Kompression für optimale Effizienz

Spezifikation

Der Dictionary-ID-Header ist im Compression Dictionary Transport Draft definiert.

Weitere Spezifikationen

Available-Dictionary Header, Use-As-Dictionary Header