Content Negotiation für RDF sauber konfigurieren

Eine Ressource, mehrere Darstellungen

Bei HTTP Content Negotiation sendet der Client im Accept-Header gewünschte Medientypen. Der Server wählt eine Darstellung oder antwortet, dass kein passendes Format verfügbar ist.

HTML und Turtle können dieselbe Ressource beschreiben, sind aber unterschiedliche Repräsentationen. Der Cache muss deshalb wissen, dass die Antwort vom Accept-Header abhängt.

Vary und Content-Type prüfen

`Vary: Accept` verhindert, dass ein Cache die Turtle-Antwort an einen HTML-Client ausliefert. `Content-Type` muss das tatsächlich gesendete Format nennen.

Redirect-Ketten sollten kurz und dauerhaft dokumentiert sein. Ein 303-Muster kann Ding und Beschreibungsdokument trennen.

Testmatrix statt Browserprobe

Testen Sie mindestens HTML, Turtle, JSON-LD, einen nicht unterstützten Medientyp und fehlenden Accept-Header. Prüfen Sie Status, Location, Vary, Content-Type und Body.

Ein Browseraufruf allein beweist nicht, dass RDF-Clients korrekt bedient werden. Automatisierte HTTP-Tests gehören zum Deployment.

Zwei überprüfbare HTTP-Anfragen

Die Befehle prüfen Header und Body getrennt für HTML und Turtle.

curl -i -H 'Accept: text/html'   https://example.org/id/produkt-42

curl -i -H 'Accept: text/turtle'   https://example.org/id/produkt-42

# Erwartet in beiden Varianten:
# Vary: Accept
# passender Content-Type oder dokumentierter 303 Redirect

Eigenständiges Redaktionsbeispiel. Reservierte example.org-Adressen bezeichnen keine realen Systeme.

Im RDF-Pfad weiterlesen

• RDF-Tripel an einem vollständigen Beispiel
• Turtle-Syntax kompakt und fehlerarm schreiben
• JSON-LD @context wirklich verstehen
• Alle RDF-Beiträge