Chapter 18. A RESTful Web Service
In this chapter, we’ll build a RESTful web service on top of the MoviesService
and 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.
Scoping the Problem
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 ...
Get Enterprise Rails now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.