MediaWiki API result
This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.
See the complete documentation, or the API help for more information.
{
"batchcomplete": "",
"continue": {
"lecontinue": "20260313112334|83",
"continue": "-||"
},
"query": {
"logevents": [
{
"logid": 93,
"ns": 0,
"title": "We\u2019re All Still Living the DHTML Dream",
"pageid": 92,
"logpage": 92,
"revid": 282,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T20:06:24Z",
"comment": "Created page with \" Modern web applications often present themselves as revolutionary, but much of what we build today is a direct continuation of ideas formed during the DHTML era. The tools have changed, the performance has improved, and the APIs are richer \u2014 but the underlying dream remains the same: dynamic, responsive, application\u2011like experiences delivered over documents. == Context == In the late 1990s and early 2000s, '''Dynamic HTML (DHTML)''' promised something radical for...\""
},
{
"logid": 92,
"ns": 0,
"title": "The XML Stack: A Dynamic Platform That Didn\u2019t Make It",
"pageid": 91,
"logpage": 91,
"revid": 281,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T20:05:36Z",
"comment": "Created page with \"Long before modern JavaScript frameworks and JSON-based APIs, the web nearly standardised on a complete, declarative application platform built from XML, XPath, XPointer, and XSLT. This article explores what that platform was, what it was capable of, and why it quietly disappeared \u2014 despite solving many problems we still grapple with today. == Context == * XML was never intended to be \u201cjust a document format\u201d. * It was designed as a structured, machine-readable da...\""
},
{
"logid": 91,
"ns": 0,
"title": "Describing HTTP Endpoints and Discovery",
"pageid": 90,
"logpage": 90,
"revid": 280,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T19:04:08Z",
"comment": "Created page with \"HTTP endpoints are the public \u201cdoors\u201d into a system. How those doors are described, exposed, and discovered determines whether an API is usable, evolvable, and maintainable. This article explains what HTTP endpoints really are, how clients discover them, and why good discovery design matters more than most people realise. == Context == HTTP was not originally designed for APIs \u2014 it was designed for '''documents linked together'''. APIs inherited HTTP, and with i...\""
},
{
"logid": 90,
"ns": 0,
"title": "Responsive Web Design: HTML Is Already Responsive, and What Print Media Taught Us",
"pageid": 89,
"logpage": 89,
"revid": 278,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T14:53:57Z",
"comment": "Created page with \"= Responsive Web Design: HTML Is Already Responsive, and What Print Media Taught Us = '''Summary:''' Responsive Web Design is often described as a modern evolution of web development \u2014 something invented to solve new problems. In reality, HTML was already responsive from the very beginning. The core behaviours we now call \u201cresponsive\u201d were present in the earliest browsers, long before mobile devices existed. This article explores why HTML was always fluid, w...\""
},
{
"logid": 89,
"ns": 0,
"title": "Progressive Enhancement and Graceful Degradation",
"pageid": 88,
"logpage": 88,
"revid": 277,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T14:42:11Z",
"comment": "Created page with \"= Progressive Enhancement and Graceful Degradation = '''Summary:''' Progressive Enhancement and Graceful Degradation are two complementary design philosophies used to build resilient, accessible, and future\u2011proof systems. They describe how a system behaves when features, capabilities, or assumptions are missing \u2014 whether by design, constraint, or failure. This article explains both approaches, where they came from, how they differ, and how they are applied in real...\""
},
{
"logid": 88,
"ns": 0,
"title": "One Data Model, Many Representations",
"pageid": 87,
"logpage": 87,
"revid": 276,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T14:35:58Z",
"comment": "Created page with \"= One Data Model, Many Representations = '''Summary:''' Modern web systems often create unnecessary separation between websites and APIs. In reality, both are simply different representations of the same underlying data. When designed correctly, a website can function as an API, and an API can render a complete website \u2014 without semantic loss, duplication, or inconsistency. This article explores that principle and the machine\u2011readable HTML technologies that make i...\""
},
{
"logid": 87,
"ns": 0,
"title": "Accessibility, ARIA, and Semantic HTML",
"pageid": 86,
"logpage": 86,
"revid": 275,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T14:06:24Z",
"comment": "Created page with \"= Accessibility, ARIA, and Semantic HTML = '''Summary:''' Accessibility is not a feature, a checklist, or an optional enhancement. It is the discipline of ensuring that meaning, structure, and behaviour remain usable when visual presentation is removed. This article explains how semantic HTML, ARIA, and backward\u2011compatible design work together \u2014 and why misuse of ARIA often makes accessibility worse, not better. == Context == Accessibility is frequently misund...\""
},
{
"logid": 86,
"ns": 0,
"title": "Digitizing Paper Forms and Business Processes - What to Remember and What to Forget",
"pageid": 85,
"logpage": 85,
"revid": 273,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T12:43:41Z",
"comment": "Created page with \"= Digitizing Paper Forms and Business Processes \u2014 What to Remember and What to Forget = '''Summary:''' Paper forms are not mistakes to be erased; they are artefacts of real work that evolved under physical constraints. When we digitize, we should preserve what paper gets right (clarity, authority, linear flow) and retire what it does poorly (long, multi\u2011party, storage\u2011heavy, silo\u2011creating processes). This article explains how to analyse the business process be...\""
},
{
"logid": 85,
"ns": 0,
"title": "Tabular Data: From Paper Ledgers to APIs",
"pageid": 84,
"logpage": 84,
"revid": 272,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T12:28:09Z",
"comment": "Created page with \"= Tabular Data: From Paper Ledgers to APIs = '''Summary:''' Long before computers existed, organisations recorded information in tables. While the technologies used to store and serve data have evolved \u2014 from paper ledgers to flat files, database servers, and modern APIs \u2014 the fundamental shape of most business data has remained remarkably consistent. This article explores that continuity, and how successive generations of systems have focused less on changing the...\""
},
{
"logid": 84,
"ns": 0,
"title": "How Computers Interact with HTTP Endpoints",
"pageid": 83,
"logpage": 83,
"revid": 271,
"params": {},
"type": "create",
"action": "create",
"user": "Dex",
"timestamp": "2026-03-13T11:45:51Z",
"comment": "Created page with \"= How Computers Interact with HTTP Endpoints = '''Summary:''' This article explains how computers programmatically communicate with remote systems using HTTP-based interfaces. It covers common web service approaches including XML-RPC, SOAP, RESTful APIs, and JSON-RPC, explaining how they differ, why they exist, and where each is still encountered in real-world systems. == Context == HTTP is often thought of as a protocol for humans using web browsers. In practice, it i...\""
}
]
}
}