Hopefully the pebbles that [RESTful Web APIs] kicks loose will have the same effect as its predecessor [RESTful Web Services] did. Who knows, perhaps in another seven years it will be time to do this all over again, and highlight some other facet of Representational State Transfer that continues to be under-appreciated.
Well, it hasn’t quite been seven years, but this is exactly where RESTful Web Clients comes in. Mike has quite the pedigree in the API space and, with this text, has brought his usual style of clarity, both in writing and in thought, to this oft-ignored part of web APIs.
Roy Fielding’s dissertation, Architectural Styles and the Design of Network-based Software Architectures, is the definitional text of REST. In the very first section, Fielding describes the seven essential architectural constraints that describe REST. The first one is called client–server, and is described like this:
Separation of concerns is the principle behind the client–server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
Clearly, servers and clients are both incredibly important to this way of designing systems. However, there’s been a bias in the works done that build on top of Fielding: almost all of them focus on the servers, and rarely discuss the clients. But doing so leaves out an incredibly important part of the picture: many of the benefits of a RESTful architecture can only be realized with a properly designed client. There are many systems which have a client-server style, but aren’t driven by the same principles as the Web. If we must adapt the way that we code servers to make them more web-like, so must we change the way we code clients.
And indeed, this is a difficult part of moving to a “web way of thinking” when it comes to building APIs. I have had many, many discussions with organizations interested in deploying hypermedia techniques who then struggle when it comes to putting them into practice. I believe that a lot of the difficulty here comes from this focus on the production of hypermedia, without also considering the changes to the way that you consume it. An API designer who expects to build a client for a web API using the same principles as other APIs is going to be frustrated with the results. Yet this is completely understandable, as those of us who advocate this architectural style have often focused almost entirely on production.
In hindsight, this deficiency seems quite obvious: how can we design systems properly if we only focus on half of the equation! I actually believe that this situation is a second-order effect of the way that the majority of people consider APIs today: my organization focuses on how to have an API for my product, but since it’s your organization that consumes it, it’s your job to deal with it. This underlying sentiment has been magnified by the trends of the last five to ten years with APIs: a move toward “simple APIs that don’t require a complex SDK to get useful work done.” An organization that provides an API client is often viewed with skepticism. We’re now starting to see this turned around, as developers grow tired of re-implementing new API clients for every API they wish to use. First-party SDKs are now being viewed in a positive light, as consumers of these APIs can focus more on their application, and worry less about integration.
As the gestalt shifts, organizations are in a position to once again consider both sides of the equation. In a broad sense, I think this will lead to even better APIs, but it’s not all roses. As I mentioned before, there are no end to the books you can purchase to help you understand the server side of the equation. But there’s a complete dearth of similar manuals for the client side—until now.
I have been eagerly awaiting this book since Mike first told me he was starting to work on it, and he has not disappointed. It is a fantastic guide to this underserved part of the web API equation, and I am confident that its impact and influence will be noted for years to come. I would tell you that I hope you’ll enjoy reading this book as much as I did, but I don’t need hope—I know you will.