In this chapter, we’ll build a RESTful web service on top of the
OrdersService applications. Much like our
user-facing public website, this application glues together the
functionality provided by each service into one unified whole. We broke
our monolithic application up into a service-oriented architecture (SOA)
to achieve a number of benefits—scalability, reusability, and
understandability of any given piece—but the collection of services are
not on their own useful. They need to be composed in a meaningful way. In
the case of our web service, we’d be providing a complete,
machine-friendly interface for third-party affiliates who might be selling
movie tickets on our behalf.
In defining our problem, we are also implicitly defining what problem isn’t. Specifically, we are not trying to provide a single interface that can be used by a machine as well as humans (other than for debugging purposes); our clients are defined to be other computer programs. Using the APIs we designed in Chapters 15 and 16 (or more likely, a more complete set), we can assume that a coherent website that composes both of our services and consumes much if not all of our API could and would be built. This concern—satisfying the need for an accessible machine-friendly API—is handled as a separate application.
While this may seem counter to what many are led to believe is the great benefit of RESTful applications—that the same interface can ...