15 Web APIs you've never heard of

[Rss Bot 1]

There is a huge number of web APIs available and sometimes as a web developer it can be hard to keep track of new ones. So we've helpfully collated a list of web APIs that are not finalised yet, but are likely to become important in the following months or years. These include APIs for handling payments, connecting to sensors and more.

To stay up to date with the latest developments you can have a look at the GitHub page of the Web Incubator Community Group, or the news page of the W3C. Stay tuned! 

01. Payment Request API

When you look at payment forms and workflows on websites and web applications they often differ from one another. However, in principle the workflow should always be the same: confirm the shopping cart, add the shipping and billing address, select the payment method, confirm everything, accept the terms and conditions and send the final request form. 

From a usability point of view this difference can actually have a negative effect. Similarly, implementing a new payment flow every time one is required can be a very time-consuming process for the developer: different forms need to be implemented, different payment methods like PayPal or credit card integrated and everything has to be secure. 

The Payment Request API currently developed by the W3C looks set to simplify the process for everyone. It aims to facilitate and standardise the process of creating payment workflows and provides several interfaces.

02. Web Share API and Web Share Target API

These APIs standardise sharing resources from one application to another

The goal of the Web Share API is to provide a standardised way of sharing resources (text, images, URLs and so on) from a mobile application to a destination specified by the user – this could be another mobile application, a website or a system service provided by the mobile OS. 

The Web Share API extends both the interface's Navigator and WorkerNavigator with a method share(), which takes the shared resource as parameter. While the Web Share API defines how to share resources, the Web Share Target API defines how to receive such shared resources. Applications (either native or web) and other services can use this API to register themselves for the share event to receive shared resources.

03. WebUSB API

USB is one of the standard ways of connecting external devices to a computer. While devices like mouse and keyboard are automatically recognised, less common devices require you to install native drivers (in other words, native code). This native code means these devices cannot then be used by browser in a standard way. 

This is where the WebUSB API comes into play: the idea is that USB devices expose their services through this API so web applications can access those services. To achieve this, the interface Navigator is extended with the property USB, which then gives you access to an object of type USB, the main entry point for this API. Using the method getDevices() you can, for example, retrieve a list of all devices that are currently available and subsequently directly start working with them.

04. Geofencing API

The Geofencing API lets you set up geographic boundaries

Today you can already determine the current geographic position of a device through the Geolocation API. However, with the new Geofencing API it will be possible to set up geographic boundaries around specific locations and get notified when a device enters or leaves those locations. The API will be based on Service Workers, so even if the Geofencing API is used in a web application that has been closed it will still receive notifications.

05. Presentation API

The Presentation API can be used to control presentations via JavaScript

There are a lot of libraries for creating presentations based on HTML5, CSS and JavaScript. However, there is no standard way to handle the interactions between the controlling part of a presentation and the actual presentation. This is where the Presentation API comes into play. 

The idea behind it is to be able to have one webpage that contains the presentation and one webpage that runs the code for controlling the presentation. Depending on the capabilities of the presenting device and the connection mechanism (DVI, HDMI, Chromecast, AirPlay and so on), either both webpages run in the same user agent (on the controlling device) or one runs in a user agent on the controlling device while the other one runs in a user agent on the presenting device.

06. Shape Detection API

The ability to detect shapes in images can be very useful (think of Facebook's face detection features) and there are some libraries available for this, like tracking.js. The Shape Detection API, which is currently in progress, defines interfaces to detect different shapes in still images or in live image feeds. 

At the current stage the API has three sub-APIs: one for detecting faces, one for detecting barcodes and one for detecting text. The three interfaces FaceDetector, BarcodeDetector and TextDetector are all used in a similar way: they all provide a method detect(), which takes an image source as input and returns a Promise object with a sequence of detected shapes.

07. Async Cookies API

The current interface to work with cookies (document.cookie) is not very comfortable: there are no standard methods for adding, reading or deleting cookies, so all of this has to be done manually via string parsing and string manipulation. Of course there are helper libraries to facilitate all of those operations, but with the Async Cookies API it will be much easier and more performant as well. 

The idea is to not only store the cookies in document.cookie, but also provide a new object named cookieStore, which will be accessible both in webpages and in service workers. The object has methods like write() and set() for adding cookies, delete() for deleting them and read() for reading cookies. They all work asynchronously, so even if some cookie processing takes longer, this will not impact on the overall performance.

08. Input Device Capabilities API

Input events like the click event are only abstract representations of the device input; they do not contain information about the actual device that has been used to generate the event. Developers need to make assumptions about which actual input device triggered such an event. 

When supporting both mouse and touch events this can lead to problems and difficulties: it is hard to find out if some event (e.g. mousedown) was triggered from the mouse (because a mouse is used) or just because of compatibility reasons (but the actual device is a touch device). 

The new Input Device Capabilities API wants to solve those problems and introduces a new interface (InputDeviceCapabilities), which provides information about the device via a new property sourceCapabilities of the UIEvent interface.

09. FlyWeb API

With the rise of the Internet of Things, how devices and electronics connect and interact with each other is becoming more and more important. The idea of the FlyWeb API, which is being developed by the Mozilla team, is to be able to serve web applications on electronics and to then connect to these applications from other electronics (for example, with smartphones) within the same network. 

Say that you want to connect a smartphone to a game console. The latter would provide a small FlyWeb server, and this would then be visible to the smartphone.

10. Push API

The Push API allows servers to push messages to the client

In traditional web applications there was no way for a server to actively send messages to a client – for example, to update a news ticker or to update some real-time data stream. Instead developers used techniques like Long Polling, XHR Polling or Hidden Frames to simulate real-time connections. Fortunately, thanks to Web Sockets and Server-Sent Events (SSEs) those techniques are not necessary any more. 

With Web Sockets you can implement a bidirectional communication between the client and the server, and with SSEs a unidirectional communication going from the server to the client, which is perfect for sending updates actively from the server to the client. However, both technologies require a browser window/tab to be open to receive those updates. 

With the new Push API this is not necessary: it is directly connected to the Service Worker API and allows service workers to receive messages from a server. This means that even if a web application has been closed, the service worker can still receive the messages – for example if you want to send notifications via the Notifications API to inform the user about any updates.

Next: 5 more new APIs you need to know about

11. Generic Sensor API

There are already a lot of Web APIs that define interfaces for different kinds of sensors (for example, the Device Orientation API and the Geolocation API). Unfortunately those APIs do not have a common interface and are all used differently – for example, by providing callback handlers in one case, or by registering event handlers in another. The goal of the Generic Sensor API is to define a set of common, generic interfaces for accessing any kind of sensor. Concrete sensor APIs that are based on the Generic Sensor API (such as the Ambient Light API) extend generic interfaces and add functionality as required.

12. Accessibility API

Accessibility is an important point when developing web applications. There are already standards like ARIA, which provides an ontology of roles, states and properties to define accessible user interfaces on the web. It can also enrich HTML elements (on a markup level) with information that can be used by assistive technologies like screen readers. 

However, the Accessibility API creates a standard Web API for JavaScript, based on ideas from ARIA and other existing accessibility APIs like Web Accessibility and Actions by Microsoft, the Web Accessibility API by Mozilla or other native platform APIs (including the Java Accessibility API). 

Using the new property a11ement on DOM elements, developers can access semantic information about the element like the role, the state, relation to other elements and many more, using JavaScript.

13. Font Loading API

With the Font Loading API you can load font faces dynamically with JavaScript

When you are using custom fonts on a webpage, downloading the font files can take time, depending on the bandwidth and the size of the font files. This can then lead to display problems, such as flickering content when the webpage starts rendering without the font face being loaded first. 

The new Font Loading API addresses this problem and it can define a standardised API for downloading font faces by utilising JavaScript. Developers can choose when to load a font face and what to do when it has been downloaded.

14. Web Bluetooth API

The Bluetooth protocol is a standard that is often used in the field of IoT, for example to connect a smartphone or tablet to other devices like health trackers to read certain sensor values. For mobile web applications it is already possible to connect via Bluetooth by using PhoneGap and its plugins, but if you want to use Bluetooth inside a web application on a desktop computer or laptop then you will still need to install an extra browser plugin. 

The goal of the Web Bluetooth API that is being worked on by the W3C Web Bluetooth Community Group is to provide a standardised API for accessing Bluetooth devices through the browser, without the need for any plugins. 

15. Visual Viewport API

The Visual Viewport API solves those layout viewport vs visual layout clashes

As you know, web applications contain two viewports: the layout viewport, which represents the space where a page lays out its elements into, and the visual layout, which represents what is visible on the screen. However, working with those two layouts can be a confusing task: while some properties like innerWidth and innerHeight are relative to the visual viewport, other properties such as those for accessing event coordinates are relative to the layout viewport. 

On top of that, the browser behaviour can also differ when you pinch-zoom into an application (an online demo that visualises those problems and the relationship between these two different layouts in general can be found here). 

To overcome these problems and disparities, the goal of the Visual Viewport API is to add new properties that are all related to the visual viewport, as well as to introduce a property visualViewport on the window object.

This article originally appeared in net magazine issue 292; buy it here!

Related articles:

• 15 APIs developers need to know
• Framework choices for developers
• 4 of the most game-changing developments in tech

View the full article