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 ...

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.