Blogging & Web Terbuka

WebSub untuk Situs Pribadi - Biarkan Feed Mengumumkan Pembaruannya

Ditulis oleh Adam Muiz 19 Oct 2026 Diperbarui: 19 Oct 2026 8 menit baca

Feed reader dapat menemukan artikel baru dengan memeriksa feed sebuah website setiap beberapa menit. Cara ini berfungsi, tetapi menimbulkan pilihan yang kurang nyaman: memeriksa lebih sering dan membuat banyak request yang tidak menemukan pembaruan, atau memeriksa lebih jarang dan menerima jeda yang lebih panjang. Bisakah sebuah situs pribadi mengumumkan bahwa feed-nya berubah tanpa menggantikan RSS atau Atom?

WebSub adalah salah satu jawabannya. Ini merupakan protokol W3C untuk mengirimkan pembaruan dari publisher kepada subscriber melalui perantara bernama hub. Sebelumnya, protokol ini dikenal sebagai PubSubHubbub. WebSub tidak menggantikan format feed dan tidak sama dengan browser push notification. Ia menambahkan jalur pengiriman server-to-server di sekitar resource HTTP yang sudah ada.

Perbedaan itu penting. WebSub dapat membuat pembaruan tiba lebih cepat dan mengurangi polling yang tidak perlu bagi subscriber yang kompatibel, tetapi tidak menjamin setiap feed reader akan memakai jalur tersebut atau membuat polling menjadi usang. WebSub juga menambahkan lease, callback, signature, serta layanan lain yang kebijakan dan ketersediaannya perlu diperhitungkan. Jadi, pertanyaan yang berguna bukan sekadar “Apakah push lebih baik daripada polling?”, melainkan “Tanggung jawab apa yang ditambahkan WebSub, dan apakah tanggung jawab itu layak untuk situs ini?”

Pertahankan feed, ubah cara pembaruan dikirim

Atom adalah format syndication berbasis XML: ia menjelaskan sebuah feed beserta entry di dalamnya. WebSub adalah protokol pengiriman. Topic-nya dapat berupa feed RSS atau Atom, halaman HTML, maupun resource HTTP atau HTTPS lainnya. Untuk situs pribadi konvensional, feed tetap menjadi topic yang wajar karena sudah menyediakan daftar posting terstruktur kepada subscriber.

Analogi yang membantu adalah papan pengumuman dan bel pintu. Feed adalah papan pengumumannya: ia memuat informasi terkini dan tetap tersedia kapan pun seseorang berkunjung. WebSub menambahkan bel pintu: subscriber dapat meminta pemberitahuan setelah papan tersebut berubah. Pemberitahuan itu tidak menghilangkan papannya, dan pengunjung yang tidak dapat memakai bel tetap bisa memeriksanya secara langsung.

Inilah alasan istilah “real time” perlu diperlakukan dengan hati-hati. Publisher dapat segera memberi tahu hub, tetapi pengiriman tetap bergantung pada hub, subscriber, kondisi jaringan, retry, dan kebijakan implementasi. WebSub menentukan jalur pembaruan; ia tidak menjanjikan latency universal atau pemrosesan exactly-once.

Empat peran dalam satu pembaruan

Protokol ini lebih mudah dipahami ketika empat istilahnya dipisahkan dengan jelas:

Topic: resource HTTP atau HTTPS yang perubahannya ingin diketahui, misalnya https://example.com/feed.atom.
Publisher: pemilik topic tersebut. Publisher mengiklankan URL yang relevan dan memberi tahu hub yang dipilih setelah ada pembaruan.
Hub: perantara yang memverifikasi permintaan subscription dan mendistribusikan konten yang diperbarui.
Subscriber: layanan yang dapat diakses melalui jaringan, meminta pembaruan, dan menerimanya pada callback URL.

Urutan tingkat tinggi dalam WebSub Recommendation saat ini adalah:

Subscriber mengambil sebuah topic lalu menemukan URL hub dan URL canonical topic-nya.
Subscriber mengirimkan permintaan subscription kepada hub.
Hub mengirim challenge ke callback subscriber untuk memastikan bahwa subscription benar-benar diminta.
Ketika topic berubah, publisher memberi tahu hub.
Hub mengirim konten topic yang telah diperbarui kepada subscriber aktif.

Publisher tidak memerlukan daftar subscriber. Hub yang mengelola hubungan tersebut. Hal ini membuat sisi publishing relatif kecil, sementara kompleksitas yang lebih besar berpindah ke hub dan subscriber.

Apa yang harus disediakan publisher kecil

Publisher yang conforming harus mengiklankan setidaknya URL hub dan URL canonical topic. WebSub menggunakan typed web links untuk discovery ini. Relasi hub yang terdaftar di IANA mengidentifikasi layanan tempat pendaftaran pembaruan tersedia, sedangkan self mengidentifikasi topic yang dipakai untuk subscription.

Link tersebut dapat dikirim dalam HTTP Link header. Untuk feed XML dan halaman HTML, link juga dapat ditanam sebagai elemen link. Subscriber memeriksa HTTP header terlebih dahulu, lalu memeriksa representation ketika header tidak menyediakan link tersebut. Model ini dibangun di atas typed relationship dan serialisasi Link header yang ditetapkan dalam RFC 8288.

Sebuah feed Atom dapat memuat link pada level feed seperti berikut:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Example Notes</title>
  <link rel="self"
        type="application/atom+xml"
        href="https://example.com/feed.atom" />
  <link rel="hub"
        href="https://hub.example.net/" />
  <!-- feed metadata and entries -->
</feed>

Domain di atas adalah placeholder, bukan rekomendasi public hub. URL self perlu diperhatikan secara khusus: inilah URL canonical topic yang dikirim subscriber kembali kepada hub. URL tersebut sebaiknya menghasilkan representation yang dituju dan tetap stabil. Jika satu endpoint melakukan negotiation untuk beberapa media type atau bahasa, spesifikasi WebSub menjelaskan bagaimana discovery dapat mengembalikan URL self yang spesifik untuk suatu representation.

Discovery hanyalah separuh pekerjaan publisher. Setelah menerbitkan topic yang berubah, publisher harus memberi tahu setiap hub yang diiklankannya. Standar ini sengaja tidak menentukan mekanisme publisher-to-hub tersebut. Sebagian hub mungkin menerima POST dengan form encoding, tetapi kebiasaan itu bukan command universal yang dapat disalin ke semua provider. Integrasi CMS harus mengikuti dokumentasi terbaru hub yang dipilih dan menangani kegagalan tanpa berpura-pura bahwa keberhasilan publish artikel bergantung pada response langsung dari hub.

Mengapa sisi subscriber lebih sulit

Menambahkan dua link ke feed memang sederhana. Membangun subscriber bukan sekadar menambahkan endpoint webhook.

Subscriber mengirim permintaan form-encoded kepada hub yang berisi callback, mode, dan URL topic hasil discovery. Hub yang dapat menangani permintaan itu mengembalikan HTTP 202 Accepted karena penerimaan tersebut dilanjutkan dengan verifikasi asynchronous. Hub kemudian melakukan GET request ke callback dengan hub.challenge acak. Subscriber hanya menggemakan challenge itu jika topic dan tindakannya cocok dengan subscription yang sedang menunggu.

Subscription merupakan lease, bukan janji permanen. Hub menentukan durasinya dan subscriber harus memperbaruinya sebelum kedaluwarsa. Ketika konten tiba, callback segera mengakui penerimaan dengan response 2xx. Menurut spesifikasi, response tersebut sebaiknya berarti “pesan sudah diterima”, bukan “setiap pekerjaan lanjutan sudah berhasil diselesaikan”. Ini memungkinkan parsing atau indexing yang mahal dikerjakan setelah acknowledgment, tetapi juga berarti subscriber membutuhkan pemrosesan durable dan observability sendiri jika kehilangan pembaruan merupakan masalah.

Pengiriman bukan exactly-once. Hub sebaiknya melakukan retry atas request yang gagal dalam batas kebijakannya sendiri, tetapi duplicate, keterlambatan pengiriman, dan kegagalan akhir tetap menjadi urusan aplikasi. Karena itu, identifier dan timestamp pembaruan pada entry feed tetap penting. Sesekali melakukan polling terhadap topic juga dapat menjadi jalur pemulihan yang berguna, bukan pengakuan bahwa gagasan push telah gagal.

Detail keamanan 2026 bukan hiasan opsional

Riwayat publikasi W3C mencatat Recommendation awal pada 23 Januari 2018 dan Recommendation baru pada 2 Juni 2026. Dokumen saat ini menambahkan mitigasi untuk risiko cross-site scripting pada verifikasi subscription. Ini menjadi alasan praktis untuk tidak mengimplementasikan WebSub hanya dari tutorial lama.

Panduan keamanan saat ini sangat merekomendasikan HTTPS untuk semua request. Subscriber sebaiknya menggunakan callback URL yang unik dan sulit ditebak, serta menyediakan hub.secret yang acak secara cryptographic. Ketika secret diberikan, hub menandatangani body distribution dengan HMAC dalam X-Hub-Signature; subscriber sebaiknya menghitung ulang signature tersebut dan membuang payload yang tidak cocok. Spesifikasi menyatakan setidaknya SHA-256 sebaiknya dipakai ketika transport itu sendiri tidak dapat dipercaya.

Verification challenge memerlukan perhatian tersendiri. Recommendation saat ini mewajibkan challenge yang dikembalikan menggunakan media type yang aman dan mewajibkan X-Content-Type-Options: nosniff. Dokumen itu juga menyarankan pembatasan challenge, seperti membatasi panjangnya dan menolak data binary. Aturan tersebut mencegah callback pada domain tepercaya berubah menjadi vektor reflected content atau download.

Signature tidak membuat setiap bagian request dapat dipercaya. Signature WebSub mencakup body, bukan sembarang request header. HTTPS tetap melindungi transport, dan subscriber harus menghubungkan delivery dengan state subscription miliknya sendiri, bukan menerima setiap POST yang kebetulan mencapai callback.

Kapan WebSub layak ditambahkan

Untuk situs pribadi, kasus yang paling jelas adalah feed publik yang stabil, publishing pipeline dengan post-publish hook yang andal, dan consumer yang diketahui memahami WebSub. Dalam keadaan tersebut, perubahan pada sisi publisher dapat tetap sederhana: mengiklankan discovery link, memberi tahu hub yang dipilih, mencatat hasilnya, dan menjaga feed tetap valid.

Alasannya menjadi lebih lemah ketika tidak ada consumer relevan yang memakai WebSub, ketika callback publik tidak memungkinkan, atau ketika dependency operasional tambahan tidak layak dipelihara. Polling memang kurang elegan, tetapi lebih mudah diperiksa, dan conditional HTTP request dapat membuatnya cukup efisien. Sebuah website kecil tidak menjadi kurang “terbuka” hanya karena memilih mekanisme yang lebih sederhana.

Ada pula perbedaan penting antara menggunakan hub dan mengoperasikan hub. Publisher dapat mendelegasikan penyimpanan subscription, verifikasi, perilaku retry, dan delivery kepada hub. Self-hosting hub mengambil kembali semua tanggung jawab tersebut. Pilihan itu mungkin tepat karena alasan kendali atau privasi, tetapi ia merupakan proyek pengoperasian layanan, bukan sekadar penambahan dua link pada feed.

Checklist adopsi yang hati-hati

Pastikan feed atau topic memiliki satu URL canonical yang stabil dan media type yang benar.
Pilih hub hanya setelah memeriksa kebijakan, batasan, dukungan keamanan, dan status operasionalnya saat ini.
Iklankan link rel="self" dan rel="hub" yang cocok dalam format yang didukung topic.
Beri tahu hub hanya setelah topic yang diperbarui dapat diambil secara publik.
Jangan menghapus akses feed normal atau menganggap setiap reader melakukan subscription melalui hub.
Jika mengimplementasikan subscriber, rencanakan lease renewal, duplicate delivery, acknowledgment cepat, validasi signature, dan response challenge yang aman.
Uji peran yang benar-benar diimplementasikan. WebSub Rocks, yang ditautkan oleh spesifikasi W3C, memiliki pengujian terpisah untuk publisher, subscriber, dan hub.
Pantau jalur publishing dan delivery, serta pertahankan polling sebagai kemungkinan fallback ketika freshness penting.

Kesimpulan

WebSub tidak mengubah feed menjadi produk yang berbeda. Ia memberi resource web yang sudah ada sebuah cara standar untuk mengiklankan hub dan memberi subscriber yang kompatibel jalur berbasis callback untuk menerima pembaruan. Bagi publisher, permukaan yang terlihat dapat tetap kecil. Namun, pada keseluruhan sistem, verifikasi, lease, retry, signature, dan kebijakan hub membuat tradeoff-nya lebih berarti.

Karena itu, WebSub bukan upgrade otomatis maupun mekanisme yang selalu berlebihan. Ia berguna ketika pengiriman server-to-server yang cepat menyelesaikan masalah nyata dan dependency tambahannya dapat dipantau serta dipelihara. Ketika kondisi tersebut tidak ada, feed yang valid dan polling yang cermat tetap menjadi desain yang masuk akal. Pertanyaan terbuka bagi setiap situs pribadi bukan apakah push terdengar lebih baru, melainkan apakah pembaca dan publishing workflow-nya benar-benar mendapat manfaat dari jalur tambahan itu.