La creación de enlaces hipermedia en un tipo de material personalizado

Question

Actualmente estoy creando un conjunto de tipos de papel personalizados para una API REST (por ejemplo, aplicación / vnd.mycompany.foo + xml) y estoy tratando de identificar los pros y los contras de dos maneras diferentes de exponer enlaces hipermedia.

Si consideramos en primer lugar lo hacen otros tipos de medios probablemente el mejor lugar para empezar es HTML. Html me permite crear enlaces tales como:

<image src="http://example.com/image.gif"/>
<a href="http://example.com/page.html"/>
<form action="http://example.com/page.html"/>
<link rel="stylesheet" type="text/css" href="theme.css" />

Lo interesante aquí es que en algunos casos hay algunas etiquetas específicas que tienen un atributo url y luego está la etiqueta de enlace genérico que utiliza el atributo rel para definir la relación.

En AtomPub, también hay algunas maneras de que los recursos están unidos entre sí

<collection href="http://example.org/blog/main" >
         <atom:title>My Blog Entries</atom:title>
         <categories href="http://example.com/cats/forMain.cats" />
</collection>

<atom:category scheme="http://example.org/extra-cats/" term="joke" />
<atom:entry>
   <link rel="edit" href="http://example.org/edit/first-post.atom"/>
</atom:entry>

La pregunta que estoy pidiendo es cuando no tiene más sentido utilizar un elemento de enlace con una relación, y cuando no tiene más sentido para añadir un atributo a un elemento existente.

por ejemplo. los enlaces AtomPub se podrían haber hecho

<collection>
      <link rel="source" href="http://example.org/blog/main"/>
         <atom:title>My Blog Entries</atom:title>
         <categories>
                <link rel="source" href="http://example.com/cats/forMain.cats"/>
         </categories>
</collection>

<atom:category term="joke">
     <link rel="scheme" href="http://example.org/extra-cats/"/>
<atom:category>
<atom:entry edit="http://example.org/edit/first-post.atom"/>

Como suele ser el caso, por escrito esta pregunta, la respuesta parece ser ahora evidente. Los enlaces necesarios se exponen como atributos y los opcionales como elementos. Sin embargo, estaría muy interesado en escuchar las opiniones de la gente sobre cómo piensan los enlaces deben ser representados.

Answer 1

Lo que me gustó XHTML 2 fue que cada elemento podría tener un enlace .

¿Por qué no aprovechar XLink para permitir que la misma funcitonality? De esa manera, no hay necesidad de elegir.

Answer 2

Creo semánticamente sus dos ejemplos Atom son equivalentes. Hay unos pocos lugares en la especificación Atom en un enlace sin relación se considera el enlace por defecto (ya sea que llamar es "sí" o "fuente" no lo recuerdo). Personalmente me gusta el segundo ejemplo AtomPub la mejor, debido a que los elementos de unión en una entrada Atom (que es el objeto más utilizado cuando se trata de Atom en general) define elementos de enlace con las relaciones, y utilizando el mismo esquema de la categoría, la recogida, y espacio de trabajo elementos significa que es más fácil de analizar w / o necesidad de conocer una gran cantidad de condiciones especiales.

Me tipo de ignorar el primer ejemplo de HTML porque HTML original nunca fue realmente destinado para la comunicación de máquina en la forma del átomo es, y por lo tanto (OMI) semánticamente comprensión HTML es más difícil y aguas abajo a un montón de reglas específicas para manejar cada diferentes tipos de etiquetas.

Answer 3

Esa es una pregunta interesante. Una forma de verlo sería diferenciar los enlaces en enlaces "informativos" que enlazan a los recursos relacionados, que el cliente puede (o no) que desee seguir para obtener más información (Como el elemento <categories> en AtomPub).

Por otro lado están los enlaces que "definen" el protocolo, es decir que "guía" el cliente a través de la secuencia de cambios de estado (Por ejemplo, publicar / editar / borrar en el caso de AtomPub, u orden / revisión / pagar en un sistema de compra) de un recurso que conforman el protocolo real (como <link rel="edit">).

En el Starbucks artículo , los autores se expanden por toda la idea la definición de un esquema (hipotético) para cambios de estado. Están usando <next rel="schema url" uri="uri for next resource state"> en lugar de Atom <link rel="..." href="...">, pero la idea general es la misma.

Por supuesto, se podría argumentar que, después de cualquier Enlace representa un estado cambiar para el cliente. Pero creo que esta distinción tiene sentido.