Webbflöde

en sidas uppdateringar, i ett format du kan prenumerera på

Vad det är

Ett webbflöde är en fil på en fast adress som listar en webbplats senaste poster i en form som program kan läsa. Varje post har en rubrik, ett datum, en identifierare som aldrig ändras och oftast själva texten, så att ett program kan hämta filen enligt ett schema och visa en människa bara det som är nytt. Det kallas också syndikeringsflöde eller bara flöde, och många säger ”RSS-flöde” om vilket som helst av dem, oavsett vilket format som ligger under.

Det som skiljer ett flöde från andra kanaler är åt vilket håll innehållet färdas. Ett nyhetsbrev skjuts ut: utgivaren håller en lista med adresser och skickar till var och en. Ett flöde hämtas: utgivaren lägger en enda fil på servern, och varje prenumerants flödesläsare hämtar den, jämför den med kopian från förra gången och behåller de poster den inte har sett förut. Utgivaren får aldrig veta vem som prenumererar, prenumeranten lämnar aldrig ut en e-postadress, och att sluta följa är en fråga om att ta bort en rad i läsaren.

Tre format bär nästan alla flöden på webben. RSS 2.0 är XML, daterar sina poster i stilen från RFC 822 (Sat, 07 Sep 2002 00:00:01 GMT) och förklaras fryst av sin egen specifikation. Atom, publicerat av IETF som RFC 4287 i december 2005, är också XML och striktare: varje flöde och varje post bär ett permanent id och en tidsstämpel i updated på formen från RFC 3339, och en författare måste anges någonstans. JSON Feed, i version 1.1 sedan augusti 2020, säger samma saker i JSON, för utvecklare som helst slipper tolka XML.

En sida talar om för program var dess flöden finns med element av typen <link rel="alternate"> i sidhuvudet, där vart och ett anger en mediatyp: application/rss+xml, application/atom+xml eller application/feed+json. Det är så en läsare hittar flödet utifrån ingenting annat än webbplatsens vanliga adress.

Varför det spelar roll

Det första beslutet är om ett flöde ska publiceras överhuvudtaget. Ett flöde är ytterligare en utdata att skriva mallar för, validera och hålla stabil i åratal, för en publik som är mindre än ett socialt nätverks. Mot det står att det är den enda prenumerationskanal som inte kräver någon plattform, något konto eller någon sändlista, och det finns ingen rankningsalgoritm mellan ett inlägg och de personer som bad om att få se det.

Det andra beslutet gäller format. Vissa läsare tar bara RSS och andra bara Atom, och det går inte att veta i förväg vilket en viss prenumerants läsare vill ha. Att publicera båda täcker luckan till priset av en mall till, och JSON Feed lägger till ett tredje för program som skrivs av folk som hellre hanterar JSON. Varje extra format är ännu en fil att hålla i takt: samma poster, samma identifierare, samma datum.

Det tredje är hur mycket text varje post ska innehålla. Ett flöde med hela texten låter folk läsa hela inlägget i sin läsare, vilket är en stor del av poängen med en läsare, och kostar utgivaren sidvisningar. Ett flöde med bara sammanfattningar skickar varje läsare till webbplatsen för varje post. Båda är försvarbara; valet står mellan hur långt texten når och hur ofta själva sidan besöks.

Oavsett svaren är adressen ett åtagande. Läsare frågar efter den URL de fick, enligt ett schema som varje läsare väljer själv (RSS låter ett flöde föreslå ett intervall i minuter med ttl, och en läsare får strunta i det), och många fortsätter att fråga i åratal. När en flödesadress väl är ute stannar den.

Så ser det ut i praktiken

Den här webbplatsen publicerar alla tre formaten från startsidan, på svenska under /sv/index.xml (RSS), /sv/atom.xml (Atom) och /sv/feed.json (JSON Feed). Kolofonen listar flödena och de tjänster som kontrollerar dem: alla tre bär hela texten, och det finns två XML-flöden i stället för ett eftersom vissa läsare bara tar det ena av dem och ingen kan veta i förväg vilket. W3C Feed Validator kontrollerar flödena i Atom och RSS, och JSON Feed Validator kontrollerar det tredje, som tjänsten från W3C inte täcker eftersom den är äldre än formatet. Tjänsten från W3C varnar för att de flesta poster har samma ändringsdatum. Sidan behåller varningen i stället för att dölja den: datumen kommer från historiken i git, och de flesta sidorna skrevs i samma fåtal commits.

Kontaktsidan erbjuder flödena som ett sätt att följa företaget utan konto, bredvid dess sociala profiler, och upprepar att alla tre bär hela texten i allt som publiceras.

De tre flödena skrivs varken för hand eller på begäran. I projektet som byggde webbplatsen genereras webbplatsen helt vid byggtid utan någon backend som körs. Samma innehållsträd ger varje sida fyra versioner, och utöver dem lägger startsidan till tre syndikeringsflöden och ett manifest för en installerbar applikation.

Var det går fel

Varje gammal post dyker upp igen som ny. Efter en omdesign, ett domänbyte eller en ändrad mall ser prenumeranterna dussintals poster som de läste för flera månader sedan. Läsare känner igen en post på dess identifierare, id i Atom, guid i RSS eller id i JSON Feed, och när den strängen ändras är posten ny för dem. RFC 4287 säger uttryckligen att en posts id ska överleva flytt, migrering och återpublicering. En permalänk är en bra identifierare bara så länge webbplatsen lovar att behålla den gamla strängen efter en flytt. Ange i RSS också vad guid är: specifikationen har isPermaLink satt till true som standard, och den här webbplatsens mall för RSS skriver ändå ut isPermaLink="true", eftersom en läsare som gissar åt andra hållet importerar varje post på nytt som en dubblett.

Flödet påstår att det har ändrats vid varje bygge. Datumet på flödesnivå flyttas varje gång webbplatsen byggs om, oavsett om något har publicerats, så program som bevakar det datumet för att hitta nyheter reagerar i onödan. Orsaken är en mall som stämplar klockan vid byggtid. RSS definierar lastBuildDate som den senaste gången kanalens innehåll ändrades, och updated på flödesnivå i Atom betyder samma sak, så datumet bör i stället hämtas från den nyaste posten. Den här webbplatsens mall för Atom tar det från den nyaste posten av just det skälet.

Flödet går inte längre att tolka efter en typografisk ändring. Läsare rapporterar att flödet är trasigt, och en validerare pekar på en odefinierad entitet i den första artikeln med ett typografiskt citattecken. XML fördefinierar fem namngivna entiteter, lt, gt, amp, apos och quot, medan HTML definierar hundratals fler. En Markdown-renderare som skriver citattecken och tankstreck som de namngivna entiteterna från HTML producerar kod som fungerar i en sida men är dödlig inuti ett XML-element. Escapa HTML-koden innan den läggs in, vilket är vad type="html" i Atom förväntar sig, eller lägg den i en CDATA-sektion, vilket RSS Best Practices Profile tillåter för content:encoded. Den här webbplatsens mall för Atom escapar sitt innehåll, och kommentaren bredvid noterar att flödet inte gick att tolka alls när innehållet skrevs ut oescapat.

Prenumeranter försvinner efter en flytt, och ingen hör om det. Ett flöde har ingen knapp för att avsluta prenumerationen och ingen lista som krymper, så det enda tecknet är tystnad. Flödets adress har ändrats, eller filen har tagits bort, och varje läsare som frågar efter den gamla URL:en får nu ett fel. Låt den gamla adressen fortsätta svara, antingen med själva flödet eller med en permanent omdirigering. Den här webbplatsen behåller sitt RSS-flöde på index.xml, standardsökvägen i den generator den byggs med, eftersom det är den adressen som befintliga läsare frågar efter; och på ett språk som webbplatsen inte annonserar skriver den ändå välformade flöden med noll poster, så att en läsare får ett giltigt dokument i stället för en 404.

Två flöden smälter ihop till ett i en prenumerationsdialog. Ett webbläsartillägg eller en läsare erbjuder ett enda flöde där sidan anger två. Två alternativa länkar med samma typ och samma titel ser för ett sådant verktyg ut som ett enda flöde, och det listar det som det såg sist. Ge varje länk en egen titel; den här webbplatsens sidor namnger sina med webbplatsens namn följt av ”(RSS)”, ”(Atom)” eller ”(JSON Feed)”.

Läs mer

Ordlista