MoviesService Object Model
We’ve now connected our two back-end services together. As we add
showtimes to the MoviesService, we
automatically add the showtimes as products in the ProductsService. And we have devised a
mechanism for the ProductsService to
inform the MoviesService when a
showtime is out of seats.
The last step is to provide an API for our thin, user-facing front-end website to retrieve movies, theatres, and showtimes for display. But designing an API can be tricky. Before rushing forward, let’s discuss some of the factors that will affect our design decisions.
In Chapter 15, we defined four best practices for designing an API. The first was “Send everything you need.” We could interpret this literally, and simply create one service API method per page type in our application, and have the back-end construct a data structure containing all needed data, in the perfect format, for every page.
While this would certainly work, it ties the front- and back-ends together a bit too tightly. The same reasoning we discovered in the discussion of module dependencies in Chapter 5 applies here as well. If the front-end depends on the back-end services, and not vice versa, then the back-end services should be as blind to the front-end as possible. It should be possible to create another, differently behaving front-end site without resorting to creating an entirely new API on the back-end to support it.
The other extreme would be to create a finely grained API, from which it would be ...
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.
