XMLHttpRequest (the basis for Ajax development) is a widely deployed API to load content from Web servers using the HTTP and HTTPs protocol: the W3C specification (formerly known as XMLHttpRequest Level 2) was meant to document the existing deployed API (with the ability to make requests on servers in a different domain, programmatic feedback on the progress of the network operations, and more efficient handling of binary content). That work is now done in the WHATWG. The WHATWG Fetch API also provides a more powerful Promise-based alternative.
By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services. Note the W3C version of the CORS specification does not reflect current implementations and will be obsoleted. The CORS mechanism is now a core part of the on-going Fetch specification in the WHATWG.
XMLHttpRequest is useful for client-initiated network requests, but mobile devices with their limited network capabilities and the cost that network requests induce on their battery (and sometimes on their users bill) can often make better use of server-initiated requests. The Server-Sent Events API allows triggering DOM events based on push notifications (via HTTP and other protocols).
Of course, an important part of using network connectivity relies on being able to determine if such connectivity exists, and the type of network available. The HTML5
onLine DOM flag, and its associated change event,
online, signals when network connectivity is not available to the Web environment (the flag is unreliable to assert that the Web environment is online).
The Resource Timing API offers to measure precisely the impact of the network on the time needed to load various resources, offering another approach to adapt a Web app to its network environment.
|HTTP Network API||XMLHttpRequest|
|Cross-domain Requests||Cross-Origin Resource Sharing|
|Server-pushed Requests||Server-Sent Events|
|Bidirectional Connections||The WebSocket API|
|On-line State||onLine DOM flag in HTML 5.1|
|Network Characteristics||Resource Timing Level 1|
Technologies in progress
The Beacon API aims at letting developers queue unsupervised HTTP requests, leaving it to the browser to execute them when appropriate, opening the door for better network optimizations.
The Push API allows Web applications to receive server-sent messages whether or not the said Web app is active in a browser window. The IETF Web-Based Push Notifications Working Group developed a companion protocol suitable to request the delivery of a push message to a user agent, create new push message delivery subscriptions, and monitor for new push messages (RFC 8030).
The work on Web Real-Time Communications also provides direct peer-to-peer data connections between browsers with real-time characteristics, opening the way to collaborative multi-devices Web applications.
Early work on a Web Background Synchronization API would provide a robust Service Worker-based mechanism to enable Web applications to download and upload content in the background, even in the absence of a running browser.
Discontinued work on the Network Information API to address discovery of the network characteristics has now been resumed in the Web Platform Incubator Community Group.