Erweiterungen des Atom Publishing Protocols
(Auszug aus "Newsfeeds mit RSS und Atom" von Heinz Wittenbrink, erschienen bei Galileo Press, 2005)
Erweiterungen sollten folgende Anforderungen erfüllen:
- Sie müssen einen Mechanismus der Auto-Discovery unterstützen, damit ein Client sie findet, ohne dass sich der Benutzer mit technischen Details beschäftigen muss.
- Sie müssen den Client über Möglichkeiten informieren, die sie zur Verfügung stellen, wenn diese nicht mit dem Service selbst schon gegeben sind.
- Der Datenaustausch mit dem Server soll nicht schwieriger sein als beim Kern der Atom-Funktionalität.
- Andere Funktionalitäten dürfen durch die Erweiterung nicht gestört werden.
Das Atom Publishing Protocol verwendet für Erweiterungen dieselben Mechanismen wie für seine Kernfunktionalität: Die Kommunikation mit dem Server läuft über URIs und HTTP-Methoden. Der Client kann die angebotenen Methoden in einer Datei, die ihm der Server zur Verfügung stellt, entdecken und vom Server Informationen enthalten. Ressourcen auf dem Server werden durch XML-Dokumente im Body der HTTP-Requests und -Responses verändert. Syntaktisch werden Namensräume benutzt, um vorhandene Dokumentformate bei Bedarf zu erweitern.
Eine Möglichkeit, das API zu erweitern, ist das bereits bekannte Verfahren, das Atom Syndikation Format mit Hilfe des Namensraum-Mechanismus zu ergänzen. Pilgrim bringt als Beispiel folgenden Eintrag, der die Kommentarfunktionalität von Movable Type benutzt und integriert:
POST /myblog/atom.cgi HTTP/1.1
Host: example.com
Content-Type: application/x.atom+xml
<?xml version="1.0" encoding="utf-8"?>
<entry xmlns=http://purl.org/atom/ns# xmlns:mt="http://www.movabletype.org/atom/ns#">
<title>My Entry Title</title>
<created>2003–11–17T12:29:29Z</created>
<mt:allowComments>1</mt:allowComments>
<content type="application/xhtml+xml" xml:lang="en">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Hello, <em>weblog</em> world!</p>
</div>
</content>
</entry>
Wenn man einen Eintrag modifiziert, wird ein entsprechendes Modifikationsdatum eingetragen.
Der Header des Requests sieht so aus:
PUT /myblog/atom.cgi/edit/1 HTTP/1.1
Host: example.com
Content-Type: application/x.atom+xml
Darauf antwortet der Server mit:
HTTP/1.1 205 Reset Content
Die entsprechenden Botschaften beim Löschen eines Eintrags sind:
DELETE /myblog/atom.cgi/edit/3 HTTP/1.1
Host: example.com
Und
HTTP/1.1 200 OK
Joe Gregorio verwendet in Extending the AtomAPI ein anderes Beispiel. Benutzer des Services LiveJournal können angeben, in welcher Stimmung ("mood") sie sich gerade befinden, wenn sie einen Eintrag verfassen. Diese Möglichkeit wird auch von dem XML-RPC-Interface unterstützt, das LiveJournal anbietet.
Um das API zu erweitern, wird als Erstes ein Namensraum festgelegt, der sich von dem der Kernelemente unterscheidet. Möglich wäre z. B. some.lj.example.com/namespace/. Wichtig ist es dann zu wissen, ob eine bestimmte Atom-Implementierung die Erweiterung unterstützt, und wenn ja, welche Möglichkeiten sie zur Verfügung stellt. Im Fall der Moods sollte der Server den Client darüber informieren, welche Moods möglich sind. Dass eine Erweiterung möglich ist, lässt sich durch eine Erweiterung der Introspektionsdatei (bzw. des über den FeedURI bezogenen Feeds) deutlich machen. Dabei wird ein eigener URI für die Ergänzung angegeben. Gregorios Beispiel für das entsprechende Fragment der introspection-Datei ist:
<introspection xmlns="http://example.com/newformat#" xmlns:lj="some.lj.example.com/namespace/">
<create-entry>http://example.org/reilly/</create-entry>
<user-prefs>http://example.org/reilly/prefs</user-prefs>
<search-entries>http://example.org/reilly/search</search-entries>
<lj:moods>http://example.org/reilly/moods</lj:moods>
</introspection>
Ein GET-Request bei dem entsprechenden URI ergibt ein Dokument, das die verschiedenen möglichen URIs auflistet:
<moods xmlns="some.lj.example.com/namespace/">
<mood>happy</mood>
<mood>sad</mood>
<mood>angry</mood>
</moods>
Der Client weiß jetzt, dass der Server die Mood-Facette unterstützt und welche Einträge hier möglich sind. Es ist jetzt nur noch nötig, die Angabe eines Moods in den Inhalt eines Eintrags zu integrieren. Auch dazu wird einfach ein Element mit einem entsprechenden Namensraum verwendet. Dieser Namensraum ist nicht mit dem Namensraum des Services selbst identisch! Gregorio gibt folgendes Beispiel:
<entry xmlns="http://example.com/newformat#" xmlns:lj="some.lj.example.com/namespace/" >
<title>My First Entry</title>
<subtitle>In which a newbie learns to blog...</subtitle>
<summary>A very boring entry...</summary>
<author>
<name>Bob B. Bobbington</name>
<homepage>http://bob.name/</homepage>
<weblog>http://bob.blog/</weblog>
</author>
<issued>2003–02–05T12:29:29</issued>
<lj:mood>happy</lj:mood>
<content type="application/xhtml+xml" xml:lang="en-us">
<p xmlns="...">Hello, <em>weblog</em> world! 2 < 4!</p>
</content>
</entry>
Ein Server, der eine Erweiterung nicht unterstützt, nennt den entsprechenden Service nicht in der Introspektionsdatei. Ein Client, der eine Erweiterung nicht unterstützt, sucht in der Introspektionsdatei des Servers nicht nach ihr. Die Erweiterung wird also von einer Software, die sie nicht unterstützt, nicht bemerkt und kann sie nicht stören.
| << zurück | vor >> |
| Tipp der data2type-Redaktion: Zum Thema Newsfeeds mit RSS und Atom bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: |
Dieses Werk ist lizenziert unter einer Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz.