Ich erstelle derzeit eine Reihe von benutzerdefinierten Medientypen für eine REST-konforme API (z. B. application / vnd.mycompany.foo + xml) und versuche, die Vor- und Nachteile von zwei verschiedenen Arten der Darstellung von Hypermedia-Links zu identifizieren / p>
Wenn ich zuerst überlege, was andere Medientypen tun, ist HTML wahrscheinlich der beste Ausgangspunkt. Html erlaubt mir Links zu erstellen wie:
%Vor%Das Interessante hier ist, dass in einigen Fällen einige spezifische Tags ein URL-Attribut haben und dann das generische Link-Tag, das das Rel-Attribut verwendet, um die Beziehung zu definieren.
In AtomPub gibt es auch einige Möglichkeiten, wie Ressourcen miteinander verknüpft sind
%Vor%Die Frage, die ich stelle, ist, wann es sinnvoller ist, ein Linkelement mit einer Beziehung zu verwenden, und wann es sinnvoller ist, einem vorhandenen Element ein Attribut hinzuzufügen.
z.B. die AtomPub-Links könnten gemacht worden sein
%Vor%Wie es häufig der Fall ist, scheint die Antwort beim Schreiben dieser Frage offensichtlich zu sein. Die erforderlichen Links werden als Attribute und optional als Elemente verfügbar gemacht. Ich würde jedoch sehr daran interessiert sein, die Meinungen anderer Menschen darüber zu hören, wie sie glauben, dass Links repräsentiert sein sollten.
Warum nicht XLink nutzen, um die gleiche Funktionalität zu ermöglichen? Auf diese Weise, keine Notwendigkeit zu wählen.
Ich glaube, semantisch sind Ihre beiden Atom-Beispiele äquivalent. Es gibt ein paar Stellen in der Atom-Spezifikation, wo eine Verbindung ohne Beziehung als Standardverbindung angesehen wird (ob sie "self" oder "source" heißt, an die ich mich nicht erinnere). Persönlich mag ich das zweite AtomPub-Beispiel am besten, weil die Verknüpfungselemente in einem Atom Entry (das am häufigsten verwendete Objekt im Umgang mit Atom) Linkelemente mit Relationen definiert und dasselbe Schema in Kategorie, Sammlung und Arbeitsbereich verwendet Elemente bedeutet, dass es einfacher ist, zu parsen, ohne viele spezielle Bedingungen kennen zu müssen.
Ich ignoriere das erste HTML-Beispiel, weil ursprüngliches HTML nie wirklich für die Maschinenkommunikation in der Art gedacht war, wie es Atom ist, und daher (IMO) semantisch HTML zu verstehen, ist schwieriger und setzt sich mit vielen spezifischen Regeln zusammen andere Art von Tag.
Das ist eine interessante Frage. Eine Möglichkeit, es zu betrachten, wäre es
Unterscheiden Sie Links in "informative" Links, die mit verwandten Ressourcen verlinken,
dass der Client folgen kann (oder nicht), um weitere Informationen zu erhalten
(wie das <categories> Element in atompub).
Auf der anderen Seite sind die Links, die das Protokoll "definieren",
d.h. das den Klienten durch die Abfolge von Zustandsänderungen führt
(z. B. veröffentlichen / bearbeiten / löschen im Fall von Atompub, oder bestellen / überprüfen / bezahlen in einem Einkaufssystem) einer Ressource, die das eigentliche Protokoll bilden (wie z
<link rel="edit"> ).
Im Starbucks-Artikel erweitern die Autoren die gesamte Idee um
Definieren eines (hypothetischen) Schemas für Zustandsänderungen. Sie verwenden <next
rel="schema url" uri="uri for next resource state"> anstelle von Atom's
<link rel="..." href="..."> , aber die allgemeine Idee ist die gleiche.
Natürlich könnte man argumentieren, dass nach dem any -Link ein Zustand repräsentiert ist Änderung für den Kunden. Aber ich denke, diese Unterscheidung macht Sinn.
Tags und Links xml rest http media-type