Todos los aquí presentes conocemos los RSS y estamos suscritos a decenas, o incluso cientos de ellos, pero seguramente pocos conocen ni el significado de las siglas (según la Wikipedia es Really Simple Syndication, pero también fue Rich Site Summary), ni mucho menos el funcionamiento interno de estas fuentes web que nos tienen al tanto de todas las novedades en nuestras páginas favoritas.
Y es normal, ya que quien use un blog, una wiki o cualquier gestor de contenido típico, no tiene que preocuparse ya que sus RSS se generan automáticamente conforme nutre de contenido a su web. Pero, ¿y si tenemos que crear nuestro RSS a mano? ¿Qué formato debemos utilizar y cómo podemos automatizar esta tarea?
RSS es un subconjunto de XML
Pues bien, básicamente el RSS no es más que un fichero XML que contiene ciertos elementos que lo definen y que serán reconocidos por cualquier navegador moderno, así como por lectores de feeds como Google Reader, Netvibes o similares. Es decir, es un subconjunto de XML con unas etiquetas determinadas. De un modo muy básico y genérico, podríamos decir que el formato de un RSS 2.0 sería el siguiente:
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
<!-- Aquí van las propiedades del canal -->
<item>
<!-- Aquí va el contenido de una entrada publicada -->
</item>
... <!-- Tantos elementos como entradas queramos -->
<item>
</item>
</channel>
</rss>
Ahora después entraremos en detalle acerca de qué hay que poner en el canal y en los ítems (las entradas), pero de momento vamos a centrarnos en lo más genérico del formato. Las únicas etiquetas obligatorias son las dos que abren el anterior extracto de código: el encabezado XML versión 1.0 con su codificación de caracteres, y un único elemento RSS versión 2.0.
Etiquetas y atributos opcionales del encabezado
Aunque nos bastaría con lo anterior, también podemos añadir estos otros dos encabezados tras el primero:
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2spanishfull.xsl"?>
<?xml-stylesheet type="text/css" media="screen" href="http://feeds.weblogssl.com/~d/styles/itemcontent.css"?>
Estos enlaces no tiene valor semántico, sino puramente estético, ya que sólo definen cómo se representará la información si visualizamos el feed en un navegador sin suscribirnos a él. Por una parte, el XSL dirá cómo transformar el XML en HTML en nuestro navegador, mientras que el CSS aplicará los estilos correspondientes a dicho HTML.
En cuanto a la etiqueta RSS, el único atributo obligatorio es la versión, pero podemos añadirle algunos más:
<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
Esto nos permitirá usar namespaces propios de itunes, atom, etc. y hacer así que se reconozca un podcast o un feed atom como extensiones de RSS.
Propiedades del canal
Cuando hablamos del canal nos referimos al origen de los posts, que puede ser una web o una sección dentro de la misma (podemos ofrecer un RSS general y otros específicos por temática, por ejemplo). Son varios los elementos utilizados para identificar un canal, muchos de ellos opcionales, pero lo normal es que tenga un aspecto similar a éste:
<channel>
<title>Genbetadev</title>
<link>https://www.genbetadev.com</link>
<description>Información sobre el sector de los
desarrolladores, el desarrollo de aplicaciones, para
móviles, desarrollo web, bases de datos, frameworks
y lenguajes de programación</description>
<language>es-ES</language>
<lastBuildDate>Tue, 08 May 2012 06:13:05 GMT</lastBuildDate>
<ttl>2</ttl>
</channel>
En <title> indicamos el título de la web o sección, siendo éste el nombre con el que el feed se guardará en el lector, a cambio que el usuario lo modifique manualmente si su lector lo permite.
El <link> es un enlace a la que consideremos como página principal, ya sea de la web o de la sección a la que corresponde el RSS.
En la <description> se debe introducir un pequeño resumen de lo que versa el feed, similar al texto con el que definimos una web cuando queremos que sea indexada por los buscadores.
El hecho de indicar un <language> no supone ninguna obligación de que el post verdaderamente esté en ese idioma, sino que más bien puede servir para la categorización por idiomas en agregadores de feeds.
Con <lastBuildDate> informamos de cuándo se generó por última vez el RSS. Es útil si no tenemos mucha periodicidad a la hora de escribir pero queremos que el lector sepa que nuestro feed no ha dejado de generarse y sigue funcionando a la perfección.
Precisamente, dependiendo de nuestra periodicidad nos puede interesar cambiar el elemento <ttl>, con el que informamos del tiempo de vida de una versión concreta del RSS. Con ello, conseguimos que el lector revisite nuestro feed cuando pasen tantos segundos como se indica en este elemento. Si publicamos un artículo al día, nos puede bastar con que el RSS se consulte cada hora y que nuestro servidor no se satura de llamadas buscando un nuevo contenido que aún no existe. Por contra, si nuestra web es de noticias, o simplemente la actualidad es uno de sus puntos fuertes, nos interesará tener un ttl bajo y asegurarnos que los usuarios puedan tener el feed actualizado casi tan pronto como el artículo se publique.
Otros elementos para el canal
Existen otros elementos que pueden aparecer en el canal, aunque de menor utilidad que los anteriores. Por ejemplo, podemos agregar una imagen identificativa, y hacer que tenga un enlace a nuestra web. Sin embargo, este dato orientado al usuario humano y no al software lector sólo será visible, en el mejor de los casos, en el momento de suscribirse, por lo que no es de gran importancia.
<image>
<url>http://blogs.es/imagenes/planet/genbetadev.jpg</url>
<link>https://www.genbetadev.com</link>
<title>Genbeta Dev</title>
</image>
Si sabemos que hay ciertas horas en las que nunca vamos a publicar nada (de madrugada, normalmente) o ciertos días de la semana en los que nunca sacamos contenidos, podemos indicar al lector que no intente actualizarse en esos periodos mediante las estructuras <skipHours> y <skipDays>
<skipDays>
<day>Saturday</day>
<day>Sunday</day>
</skipDays>
<skipHours>
<hour>0</hour>
<hour>1</hour>
<hour>2</hour>
<hour>3</hour>
<hour>4</hour>
<hour>5</hour>
<hour>6</hour>
<hour>7</hour>
<hour>20</hour>
<hour>21</hour>
<hour>22</hour>
<hour>23</hour>
</skipHours>
Si queremos que los derechos de los artículos queden patentes en el propio RSS aparte de en nuestra web de destino, podemos agregar un elemento <copyright> con el texto correspondiente.
Del mismo modo, si queremos que quede constancia de la aplicación con la que hemos generado el feed, podemos indicarlo añadiendo el tag <generator>.
Por último, antes de pasar a las entradas que suponen el verdadero contenido del RSS, si hemos añadido namespaces de feedburner, itunes y otros servicios de terceros, lo normal es que tengamos algunos elementos pertenecientes a dichos namespaces y que se regirán por las restricciones de formato que cada uno de ellos imponga, por lo que no vamos a verlos aquí.
Las entradas
Cada una de las entradas o posts que queremos notificar a nuestros suscriptores vendrá definida por un elemento <item>, que entre elementos obligatorios y los muy recomendables, suele ser como mínimo algo similar a esto:
<item>
<title>Diagrama para elegir la licencia más
apropiada para tu software</title>
<link>
http://weblogssl.feedsportal.com/c/33859/f/609642/s/1f17063b/l/0L0Sgenbetadev0N0Csoftware0Elibre0Ey0Elicencias0Cdiagrama0Epara0Eelegir0Ela0Elicencia0Emas0Eapropiada0Epara0Etu0Esoftware/story01.htm</link>
<description><p><img alt="Cabecera infografía licencias libres"
src="http://img.genbetadev.com/2012/05/Cabecera_licencias.jpg" class="centro_sinmarco"
/><br /> Ponerle copyright a un software y <em>sentarse a esperar los
beneficios</em> es muy fácil, pero si alguna vez has pensado
<strong>aplicar una licencia libre</strong> al fruto de tus trabajos te
habrás encontrado con que es una decisión bastante complicada,
especialmente por el <strong>amplio abanico de licencias</strong>
disponibles y las a veces muy sutiles diferencias entre unas y otras.</p>
<p>Como método de ayuda a la hora de elegir, y a mitad de camino
entre el estudio exhaustivo y el sentido del humor, <a
href="https://twitter.com/#%21/dbentley">Dan Bentley</a> y <a
href="https://twitter.com/#%21/therealfitz">Brian Fitzpatrick</a> han
creado esta infografía en forma de <strong>diagrama de
flujo</strong> para ayudarnos en la decisión en favor de una u otra
licencia.</p> <p>Yo lo he seguido y me sale que debería usar
la <span class="caps">LGPL</span> en mis desarrollos. ¿Y a vosotros?
</description>
<pubDate>Mon, 07 May 2012 13:30:00 GMT</pubDate>
<author>Johnbo</author>
<guid isPermaLink="false">
https://www.genbetadev.com/software-libre-y-licencias/diagrama-para-elegir-la-licencia-mas-apropiada-para-tu-software</guid>
</item>
El elemento <title>, como su propio nombre indica, es el título del artículo. En lectores de feeds con formato minimalista será lo único que veamos. Normalmente, lo ideal es que coincida al 100% con el título de la entrada en la web, aunque en casos de títulos muy largos, puede ser conveniente utilizar una versión reducida para que se visualice en el feed.
El otro elemento fundamental de las entradas es el <guid>, un identificador unívoco para nuestra entrada. La importancia del GUID radica en el hecho de que, manteniéndolo, podemos realizar cualquier cambio dentro del resto del ítem, y por lo general los agregadores lo seguirán tratando como el mismo post, mientras que si cambiamos el GUID, aunque todo lo demás permanezca invariable, lo más probable es que nuestro lector duplique la entrada, al considerar que cada GUID correspondía a un artículo distinto. La forma más sencilla de asegurarse que sea único y que no vaya a variar es utilizar como identificador la URL de destino, aunque esto no significa que al clicar vayamos a llegar seguro a esa dirección. De hecho, al darle el valor falso a su atributo isPermaLink (que por defecto es verdadero) le estamos indicando que no debe interpretarse como una URL al uso.
Esto se debe a que quien realmente nos indica el destino es el elemento <link>, que puede coincidir (o no) con el GUID. Hoy día, donde las analíticas web cobran tanta importancia, lo normal es que este enlace no nos lleve directamente a la página de destino, sino que nos haga pasar por una página intermedia que haga las veces de contador, ya que un lector de feeds que no tenga interfaz web normalmente no proporcionará un referer adecuado para poder medir la influencia del RSS.
La mayoría de discrepancias están a la hora de elegir el contenido del elemento <description>, ya que hay quien calza ahí el artículo completo, hay quien pone los primeros dos o tres párrafos y hay quien se contenta con apenas un abstract. La decisión dependerá de qué consideración tenemos hacia nuestros usuarios. Ponerles únicamente un breve resumen para obligarles a que te visiten, generándote ingresos por publicidad, puede hacer que la gente acabe por adoptar una actitud reacia, o incluso que el artículo no les interese porque no les has mostrado la parte más atractiva. Poner el artículo completo suele ser una buena alternativa, ya que tratas respetuosamente al usuario y sólo le haces ir a tu web para interactuar (escribiendo comentarios, por ejemplo), aunque tiene la pega de que los artículos de gran longitud se pueden llegar a ver como un estorbo dentro del lector.
En cuanto a su formato, no es necesario que sea texto plano, sino que podemos usar HTML igual que en la propia entrada, con unas salvedades bastante obvias. En primer lugar, los caracteres < y > han de introducirse con sus entidades HTML correspondientes < y > para evitar que sean reconocidas en el propio XML. En segundo lugar, hay que tener cuidado de convertir en absolutas todas las rutas relativas de imágenes u otros recursos, así como permitir en nuestro servidor el hotlinking para esos archivos desde los dominios de los principales lectores de noticias. Y por último, saber que el lector no va a reconocer estilos más allá de los más básicos: <strong>, <em>, etc.
Elementos opcionales para una entrada
El <pubDate> es la fecha de publicación del artículo. En principio debería servir para ordenar las entradas dentro del feed, pero lo cierto es que muchos lectores la ignoran y las muestran por orden estrictamente secuencial, por lo que su finalidad principal es simplemente informar al usuario de cuándo se publicó. Importante: para no marear, lo mejor es usar la hora GMT, y que ya el software del lector se encargue de traducirlo a la zona horaria del usuario.
Otro elemento no obligatorio dentro de un <item> relativamente habitual es el <author>, aunque sólo en blogs con varios articulistas, ya que en páginas llevadas por una única persona no tiene mucho sentido confirmar su autoría en todos y cada uno de ellos. En un inicio se solía indicar aquí el e-mail del autor, pero debido a los medios automatizados para spammear, actualmente se suele usar el nombre propio o un apodo.
Mucho menos habitual es encontrar el elemento <comments>, cuyo contenido es un texto con comentarios con respecto a la entrada, o incluso el enlace a una segunda URL donde encontrar esos comentarios. Al no haber limitación de tamaño en la descripción, este elemento aporta muy poco a la misma.
Con <enclosure> tenemos la posibilidad de adjuntar un archivo al RSS, aportando su URL, longitud y tipo. Dado que la descripción podía contener algunos objetos incrustados, no es muy habitual usar esta construcción para añadir uno al final.
<enclosure url="http://www.direcciondelrecurso/archivo.mp3"
length="3000000"
type="audio/mpeg" />
Para finalizar, el elemento <category> permite agrupar los posts por su temática, de forma que los agregadores RSS puedan mostrar los distintos feeds organizados por categorías. Tanto el canal como cada uno de los ítems puede pertenecer a una o más categorías.
¿Cómo generarlo?
Bueno, ya sabemos en qué consiste el formato de un RSS al detalle, pero aún no hemos dicho cómo podemos generarlo. Mientras en el mercado existen herramientas de pago como Feed for all, ya que somos programadores vamos a ver cómo haríamos para generarlo nosotros mismos sin depender de terceros.
El problema se reduce a tener un fichero llamado rss.xml y ser capaces de parsearlo para añadir un nuevo ítem cada vez que tengamos una actualización. Lo normal es que usemos el mismo lenguaje con el que hemos desarrollado la página y aprovechemos el momento en que se publica el contenido para añadir una nueva función que genere dicho XML.
El cómo hacerlo ya dependerá del lenguaje utilizado y las librerías de tratamiento de XML con las que cuente, ya que mientras algunos nos permiten de forma muy sencilla parsear un XML, movernos por él y añadir o eliminar elementos a nuestro antojo; es posible que otros menos modernos no dispongan de esta capacidad y no nos quede más remedio que abrir el archivo en modo texto y movernos por él secuencialmente buscando patrones para encontrar el lugar de inserción del nuevo elemento, que habremos de añadir también como si de una simple cadena de texto se tratase.
Más información | w3schools.com – RSS Tutorial
En Genbeta Dev Respuestas | ¿Cómo crear una RSS para mi web?