Service-Driven Computing with APIs: Concepts, Frameworks, and Emerging Trends

Service-Driven Computing with APIs: Concepts, Frameworks, and Emerging Trends

Hiranya Jayathilaka, Chandra Krintz, Rich Wolski
DOI: 10.4018/978-1-4666-6178-3.ch015
(Individual Chapters)
No Current Special Offers


While both SOAP and REST have been used widely to implement Web services and software integration, over time REST has emerged as the predominant approach. REST provides developers with a lower barrier to entry for implementation and greater development flexibility than SOAP. Its architectural conventions and best practices can be integrated into Web services incrementally as opposed to the all-or-nothing adoption of SOAP. In order to achieve generality, SOAP standards are extensive, rigid, and complex. This complexity can lead to implementations that introduce significant overhead on the network bandwidth consumption, execution times, and throughput of SOAP services, especially in the emerging resource-restricted mobile realm. This chapter provides an overview of the logical and physical design of modern Web services and discusses the strengths and weaknesses of the predominant styles. It provides evidence and reasoning behind the emergence of REST as the leader for the development of next-generation Web APIs and services. The chapter also delineates the key technologies that underlie REST and describes emerging and future research directions in support of REST-based APIs and service development.
Chapter Preview


Web services (W3C, 2004b) simplify the development of network-accessible distributed applications by combining the ubiquity of the Internet with familiar protocols of the World Wide Web (WWW), well-defined interfaces, and easily integrated software architectures. They expose functionality, business logic, and data as network-enabled modules, which can be consumed over the network by client applications written in a variety of programming languages. The Web service design and development model which utilizes Service Oriented Architecture (SOA), describes how to architect, reuse, and integrate Web service modules as the building blocks for new systems and services (Dan, Johnson, & Carrato, 2008). SOA is used increasingly for a wide range of application domains including business collaboration and productivity, Web/mobile access and communications, large scale data integration and analysis, multi-player games, and Cloud computing (compute resources, software, and data “as-a-service”) (Haines & Haseman, 2009). Many industry technology leaders (e.g., Google, Yahoo, Amazon, eBay, and Facebook) use SOA as the basis of their products, which they expose to external developers for integration with new products, services, and platforms.

Systems implemented using Web services and SOA principles tend to be loosely coupled and resilient to change, failure, and interruption (Offermann, Hoffmann, & Bub, 2009). The modular nature of Web services promotes separation of concerns, and makes it easier to design and reason about distributed applications. In addition, Web service encapsulation enables developers to choose the most appropriate programming language and technologies for their implementations and to isolate change across complex systems. This service-driven approach for developing applications minimizes code duplication and eases the assembly of complex systems, thereby greatly improving developer productivity over non-service-oriented methodologies. By composing an application from existing services that encapsulate common tasks such as database access, logging, and security; application developers can work at a higher level of abstraction, thereby saving development and debugging time. In particular, the reuse of services as modules increases reliability and stability in the resulting software system, since testing and quality assurance can focus on integration rather than on the constituent services.

Logically, a Web service consists of four primary components:

  • An architecture that governs the logical organization of data, code, and communication of the service.

  • Abstraction that hides the implementation details of the service and that enables the service architect to control the functionality that is exposed to users and other programs (service clients).

  • An implementation that contains program code for computation and data manipulation that is executed when a client accesses the service.

  • An application-programming interface (API) that defines and controls the operations that clients perform to access the implementation as specified by the abstraction layer.

The architecture and abstraction are the logical constructs of Web service design and the API and implementation comprise its physical manifestation. From an implementation perspective, APIs decouple the functionality necessary to allow controlled access to a service from the technologies that are used to implement the functionality of the service itself (Beyer, Chakrabarti, & Henzinger, 2005). That is, the API preserves the service functionality for clients accessing the service while the technologies used to implement it can change, particularly as technological advances reduce implementation costs. Similarly, it is possible for a user to swap in/out similar services if the APIs are compatible, with minimal client program modification.

Key Terms in this Chapter

API Discovery: The process of identifying available and appropriate Web services by clients (service consumers), that is facilitated through automation.

Web API: The network-accessible interface of a Web service through which remote users can interact with the service.

Web Service: A software component with a well defined interface that can be accessed over a network and which supports interoperable machine-to-machine interaction using open standards and protocols.

HATEOAS (Hypermedia as the Engine of Application State): A fundamental constraint employed in the REST architectural style, whereby client applications determine their state and state transitions entirely based on the dynamic hypermedia information provided by the servers.

QoS (quality of service): Constraints placed on Web services that describe the minimum service levels (performance, security, scale) that the provider can guarantee.

API Description Language: A markup language that enables developers to describe the functionality of the API and its operations to users/clients.

Resources: The key data and code abstractions that serve as the basis of all RESTful Web service interactions.

REST: An architectural style for implementing distributed systems based on stateless design, client-server interaction model, layering, uniform interfaces, and hypermedia driven state transitions.

Service Oriented Architecture (SOA): The architectural paradigm in which new applications are developed by reusing and combining existing Web services.

SOAP: A set of standards that define an architecture for developing, hosting, and managing Web services based on remote procedure calls for computation and messages encoded using XML for communication.

Complete Chapter List

Search this Book: