Arsip Feed untuk Website Personal - Menjaga Riwayat Tanpa Menganggap Pagination Sudah Lengkap
Sebuah website personal dapat menerbitkan ratusan tulisan, sementara feed-nya hanya menampilkan dua puluh tulisan terbaru. Itu sering kali cukup bagi pelanggan rutin, tetapi menyisakan pertanyaan yang agak sulit: jika seorang pembaca datang terlambat atau melewatkan beberapa pembaruan, apakah feed menyediakan jalur yang terdefinisi menuju entri lama, atau hanya menampilkan jendela yang terus bergerak?
Menambahkan ?page=2 terlihat seperti jawaban yang jelas. Namun, pagination saja tidak menjelaskan apakah halaman kedua akan berisi entri yang sama besok, apakah client dapat merekonstruksi riwayat website, atau apakah entri yang tidak ada harus dianggap telah dihapus. RFC 5005, Feed Paging and Archiving, memisahkan persoalan ini dengan mendefinisikan feed lengkap, feed berhalaman, dan feed berarsip. Perbedaannya sudah lama dirumuskan, tetapi pertanyaan penerbitannya tetap berguna: janji apa yang diberikan setiap dokumen feed tentang koleksi yang lebih besar?
Satu dokumen feed belum tentu merupakan seluruh feed
RFC 5005 membedakan feed document dari logical feed. Dokumen adalah satu file Atom, atau dokumen sindikasi serupa, yang diambil dari satu URL. Logical feed adalah seluruh kumpulan entri yang terkait dengannya. Satu dokumen dapat mewakili seluruh kumpulan tersebut, potongan sementara, atau bagian stabil dari sebuah arsip.
Ini mirip katalog perpustakaan yang ditampilkan satu layar dalam satu waktu. Satu layar merupakan representasi katalog, bukan otomatis keseluruhan katalog. Sebelum mengikuti tautan halaman, software perlu mengetahui apakah layar-layar tersebut merupakan hasil pencarian yang terus bergeser atau rak yang tetap.
Atom sendiri mengizinkan dokumen feed memuat sebagian atau seluruh entri terkait, tetapi menyerahkan detail rekonstruksi di luar cakupannya. RFC 5005 menambahkan kosakata untuk hubungan yang belum dijelaskan itu. Standar ini tidak mewajibkan setiap blog menerbitkan seluruh riwayatnya, dan tidak menjadikan feed tulisan terbaru biasa sebagai sebuah kesalahan.
Tiga model memberikan janji yang berbeda
Feed lengkap: dokumen ini adalah keseluruhan kumpulan
Feed lengkap secara eksplisit menyatakan bahwa satu dokumen memuat setiap entri dalam logical feed. Feed ini menggunakan elemen kosong fh:complete dari namespace feed-history. Jika sebuah entri tidak ada, consumer seharusnya tidak menganggapnya sebagai bagian dari logical feed tersebut.
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>Example Reading List</title>
<fh:complete />
<!-- every entry in this logical feed -->
</feed>Model ini dapat cocok untuk koleksi terbatas seperti daftar bacaan saat ini. Biasanya model ini kurang menarik untuk blog dengan riwayat yang terus bertambah. Lebih penting lagi, penanda tersebut merupakan pernyataan tentang kelengkapan, bukan extension dekoratif. Publisher tidak seharusnya menambahkannya ke jendela dua puluh entri hanya karena dokumen itu merupakan Atom yang valid.
Feed berhalaman: navigasi tanpa riwayat yang stabil
Feed berhalaman membagi entri ke beberapa dokumen yang saling terhubung dengan relasi seperti first, last, previous, dan next. Menurut RFC 5005, setidaknya satu dari relasi tersebut harus ada pada dokumen feed berhalaman, disertai sebanyak mungkin relasi yang relevan dan praktis.
Caveat yang penting adalah isi setiap halaman tidak dijamin tetap stabil. Anggap halaman pertama memuat tulisan 101 sampai 110 dan halaman kedua memuat 91 sampai 100. Tulisan baru yang masuk ketika client sedang menelusuri halaman dapat menggeser batasnya. Client mungkin melihat satu entri dua kali dan melewatkan entri lain. Karena itu, RFC 5005 menyebut feed berhalaman bersifat lossy dan menyatakan bahwa client seharusnya tidak menampilkannya sebagai sesuatu yang koheren atau lengkap.
Hal itu tidak membuat pagination menjadi tidak berguna. Pagination cocok ketika client menginginkan potongan terdekat dan rekonstruksi persis bukan tujuannya. Kesalahannya adalah menyebut daftar yang terus bergerak sebagai arsip hanya karena pengguna dapat terus mengeklik “next”.
Feed berarsip: bagian stabil yang terhubung ke masa kini
Feed berarsip dirancang agar dokumen-dokumennya dapat digabungkan untuk merekonstruksi logical feed secara akurat. Model ini memiliki satu subscription document yang memuat entri terbaru yang ditambahkan atau diubah, serta satu atau beberapa archive document yang memuat entri lama.
Subscription document menunjuk ke belakang dengan prev-archive. Archive document dapat melanjutkan rantai itu, menunjuk ke depan dengan next-archive, dan mengidentifikasi subscription document aktif dengan current. Registry Link Relations IANA masih mencatat relasi-relasi ini beserta definisinya dari RFC 5005.
Seperti apa arsip Atom kecil
Potongan berikut hanya ilustrasi, bukan klaim tentang dukungan feed reader saat ini. Subscription document aktif menampilkan entri terbaru dan menunjuk ke arsip lengkap yang paling baru:
<feed xmlns="http://www.w3.org/2005/Atom">
<title>Example Notes</title>
<link rel="self" href="https://example.com/feed.atom" />
<link rel="prev-archive"
href="https://example.com/feed/archive/2026-10.atom" />
<id>https://example.com/feed.atom</id>
<updated>2026-11-08T00:00:00Z</updated>
<!-- newest entries -->
</feed>Arsip Oktober yang telah selesai mengidentifikasi dirinya sebagai arsip, menunjuk ke subscription document saat ini, dan secara opsional menautkan arsip lengkap di sebelahnya:
<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:fh="http://purl.org/syndication/history/1.0">
<title>Example Notes - October 2026 Archive</title>
<link rel="self"
href="https://example.com/feed/archive/2026-10.atom" />
<link rel="current" href="https://example.com/feed.atom" />
<link rel="prev-archive"
href="https://example.com/feed/archive/2026-09.atom" />
<fh:archive />
<id>https://example.com/feed/archive/2026-10.atom</id>
<updated>2026-10-31T23:59:59Z</updated>
<!-- stable archived entries -->
</feed>RFC 5005 menyatakan bahwa subscription document atau archive document harus memuat prev-archive, kecuali tidak ada arsip sebelumnya. Sebuah arsip sebaiknya memuat next-archive ketika ada arsip lengkap yang lebih baru, sebaiknya mengidentifikasi subscription document dengan current, dan sebaiknya memuat fh:archive. Perbedaan kata tersebut penting: spesifikasi tidak memberikan tingkat kewajiban yang sama kepada setiap field.
Stabilitas arsip adalah kontrak utamanya
RFC 5005 menyatakan bahwa entri pada suatu URL arsip dan URL itu sendiri sebaiknya tidak berubah seiring waktu. Stabilitas tersebut memungkinkan consumer mengingat bahwa ia sudah memproses sebuah arsip, alih-alih berulang kali mengunduh dan merekonsiliasinya.
Path berbasis tanggal dapat membuat organisasi ini mudah dipahami, tetapi tanggal tidak menciptakan stabilitas dengan sendirinya. CMS yang membangun ulang file bulanan lama dengan batas berbeda setelah setiap penyuntingan tetap melanggar ekspektasi tersebut. Pertanyaan desain yang praktis adalah di mana batas arsip dicatat. Arsip yang tahan lama membutuhkan aturan keanggotaan tersimpan atau mekanisme deterministik lain yang tidak akan diam-diam memindahkan entri antardokumen.
Ini juga menjelaskan mengapa arsip yang masih disusun tidak seharusnya ditautkan seolah-olah sudah lengkap. Dalam contoh RFC 5005, arsip selesai yang paling baru tidak memiliki tautan next-archive menuju bulan berjalan. Subscription document aktif membawa perubahan terbaru sampai sebuah arsip dapat diperlakukan sebagai stabil.
Koreksi membuat sifat tetap menjadi lebih rumit
“Stabil” tidak berarti kesalahan fakta harus dipertahankan selamanya. RFC tersebut mengakui adanya tradeoff: beberapa client mungkin tidak mengunjungi kembali arsip yang sudah diproses. Ketika koreksi harus sampai kepada consumer, publisher sebaiknya mempertimbangkan untuk menempatkan entri yang direvisi di subscription document juga, bukan hanya menyunting arsip lama.
Perilaku itu bergantung pada identitas entri yang tahan lama. Untuk arsip Atom, entri dengan atom:id yang sama merupakan duplikat. Consumer sebaiknya mempertahankan entri dengan atom:updated terbaru; jika timestamp tidak menyelesaikan pilihan, panduan RFC 5005 mengutamakan entri dari dokumen feed yang diperbarui lebih baru.
Ini tidak membuat setiap koreksi pasti terlihat di setiap client. Model tersebut mendefinisikan cara rekonstruksi bagi consumer yang patuh. Publisher tetap tidak dapat menyimpulkan dukungan software saat ini hanya dari usia atau status standar, sehingga setiap janji khusus produk membutuhkan pengujian interoperabilitas nyata.
Consumer harus mencurigai rantai tersebut
Rantai arsip adalah input dari jaringan, bukan linked list tepercaya. Sebuah dokumen dapat menunjuk dalam loop, mengarah ke arsip yang tidak tersedia, atau menghasilkan rangkaian request yang praktis tidak berakhir. RFC 5005 memperingatkan tentang request berlebihan dan konsumsi resource. Consumer yang berhati-hati memerlukan batas jumlah dokumen, byte, waktu, redirect, dan URL yang sudah dilihat.
Jika sebuah arsip hilang, consumer mungkin tidak dapat merekonstruksi logical feed. Spesifikasi menyatakan bahwa client sebaiknya memberi tahu pengguna ketika rekonstruksi tidak lengkap. Menampilkan riwayat parsial sebagai sesuatu yang lengkap akan menghapus perbedaan yang hendak dinyatakan oleh model arsip tersebut.
Praktik dasar feed tetap berlaku. Dokumen Atom harus tetap well-formed, ID entri harus stabil, dan timestamp harus mempertahankan makna yang dimaksud. Introduction to Atom dari W3C merupakan checklist struktural yang berguna, sementara RFC 4287 tetap menjadi spesifikasi format yang otoritatif.
Ketika feed entri terbaru sudah cukup
RFC 5005 bukan syarat untuk mengoperasikan blog yang baik. Feed biasa berisi entri terbaru sering menjadi pilihan yang lebih tepat ketika pembaca hanya memerlukan pembaruan, arsip HTML sudah mendukung penelusuran, dan tidak ada consumer yang diketahui membutuhkan riwayat feed yang dapat direkonstruksi mesin.
Feed berarsip menjadi lebih masuk akal ketika kehilangan entri lama memiliki dampak nyata, file arsip stabil dapat dipelihara, dan setidaknya ada satu consumer sasaran yang diketahui mengikuti relasi tersebut dengan benar. Feed berhalaman cocok untuk eksplorasi ketika pergeseran batas dapat diterima. Feed lengkap cocok untuk kumpulan yang benar-benar terbatas. Pemilihan di antara ketiganya sebaiknya dimulai dari semantik, bukan dari pola URL mana yang paling mudah dibuat.
Sebelum menambahkan tautan arsip, publisher dapat bertanya:
- Apakah tujuannya navigasi di sekitar entri atau rekonstruksi yang dapat diandalkan?
- Dapatkah URL setiap arsip lengkap beserta keanggotaannya tetap stabil?
- Apakah koreksi penting akan kembali ke subscription document dengan ID entri yang sama?
- Dapatkah tautan rusak dan riwayat yang tidak lengkap dideteksi, bukan disembunyikan?
- Apakah reader atau tool downstream yang dituju benar-benar sudah diuji?
Kesimpulan
Feed yang dibagi ke beberapa URL tidak otomatis menjadi arsip. Feed berhalaman menawarkan navigasi melalui potongan yang berubah; feed berarsip menjanjikan bagian stabil yang dapat dirangkai; feed lengkap menyatakan bahwa satu dokumen adalah seluruh logical feed. Setiap model menjawab pertanyaan yang berbeda.
Untuk website personal kecil, feed entri terbaru yang paling sederhana mungkin tetap sepenuhnya memadai. Jika riwayat machine-readable yang tahan lama menjadi kebutuhan, RFC 5005 memberikan lebih dari sekadar tautan tambahan: standar ini menyediakan kosakata untuk menyatakan makna tautan tersebut. Bagian tersulitnya bukan menghasilkan prev-archive, melainkan menepati janji stabilitas dan koreksi di baliknya.