A Web API Ecosystem through Feature-Based Reuse

Ruben Verborgh, Michel Dumontier
2018 IEEE Internet Computing  
The fast-growing Web API landscape brings clients more options than ever before-in theory. In practice, they cannot easily switch between di erent providers o ering similar functionality. We discuss a vision for developing Web APIs based on reuse of interface parts called features. Through the introduction of 5 design principles, we investigate the impact of feature-based reuse on Web APIs. Applying these principles enables a granular reuse of client and server code, documentation, and tools.
more » ... gether, they can foster a measurable ecosystem with cross-API compatibility, opening the door to a more exible generation of Web clients. Why can people easily navigate websites they've never encountered before? The answer is simple: because interactions patterns are reused across websites. Usability expert Jakob Nielsen observed that "users spend most of their time on other websites", reminding interaction designers and information architects to compose websites from shared patterns rather than custom ones. For example, the user interfaces to update a status message on Facebook, Twitter, and Instagram are all highly similar. The strength of reuse is confirmed by the survival of visually less obvious patterns, such as a site's logo doubling as a homepage link, or three parallel lines forming a menu button on mobile devices. From a technical perspective, we could say people are "loosely coupled" to welldesigned websites, because they bind to generic interaction patterns rather than specific interfaces. The human Web maintains usability by tapping into an evolving ecosystem of interaction patterns, only inventing new interfaces as a last resort. In contrast, the machine-based Web is characterized by a near-total lack of interface-level reuse, as even Web APIs with highly similar functionality often expose very different machine interfaces. This results in a lack of substitutability 1 with non-native services: 2 clients programmed for a specific API task (such as posting a photo on Facebook) cannot perform that same task with another Web API (posting that same photo on Twitter or Flickr). Regardless of whether we classify the coupling between a client and an API as "loose" or "tight", 3 switching API providers proves difficult 4 as clients are forced to bind to a provider-specific interface rather than a provider-independent, abstract interface. Case in point: whereas Facebook and Twitter show a near-identical user interface for updating a status (a light-colored textbox with an encouraging question and a camera icon), the corresponding interactions with their Web APIs require a different number of HTTP requests with entirely different JSON bodies. If the human Web were designed in such a way, information consumption would slow down significantly, as accessing any new website would involve studying its documentation first-as is the case with Web APIs. 5
doi:10.1109/mic.2018.032501515 fatcat:6pq27lfbr5dyvcxbgwuxlwhpei