Foreword

News flash: the web is kind of a Big Deal.

It is difficult to consider its full impact on technology, society, commerce, education, governance, and entertainment without resorting to grand language that has been stated many times before. It is a Big Deal and we will never be the same because of it.

But, here’s the thing. If we sat down and tried to rebuild the web today, knowing what we know from 20 years of experience with it, we would probably fail. The problem is that as software developers, we generally think in terms of software constructs: objects, services, methods, etc. While useful from a solution space perspective, they can induce coupling and coupling does not scale.

The web works because in its design, Sir Tim Berners-Lee and his cohorts embraced the notion of change. The thing we forget is that they were not trying to build the web that we know; they were trying to build a system that worked for a dynamic organization such as CERN. Logically named resources could be requested and manipulated with no regard to how back-end systems worked. New shapes of information could be negotiated over time without disrupting deployed systems. Clients and servers could evolve independently.

The REpresentational State Transfer (REST) architectural style embraced these ideas and began to describe how to build flexible, scalable, change-tolerant systems. The primary shift was away from implementation details and toward the information that flows through the infrastructure. Clients were less cognizant of what to expect and more reactive to what they were told. The focus was on the properties induced by the architectural choices, not the technologies used to implement the solutions.

This is an important point because most REST frameworks built in languages such as Java ignore these distinctions. Their choices reflect a desire to bend REST to a privileged Java world view, not the other way around. What makes REST special and interesting is lost in the process, which is why I think most of them ultimately fail. Jérôme’s work on Restlet struck me as having the appropriate perspective: how can we conveniently surface the ideas of REST in a language like Java without debasing the goals of the architectural style.

He tackled the problem from both the client and the server perspectives. He introduced objects that stood for a Resource itself. He turned concepts such as content negotiation and metadata management into registered services, outside of the concerns of these resources. He embraced the idea of logically named protocols to extend the idea of REST into the framework with tools like the Restlet Internal Access Protocol (RIAP) and the Class Loader Access Protocol (CLAP). He understood the value of getting the APIs to a consistent, uniform place before declaring success. The resulting framework is cleaner, more flexible, and more true to the spirit of REST than any other language-based approach I have seen.

While the Restlet documentation has always been adequate, as I introduced the API in my talks and courses, I longed for a solid book on the subject. I even toyed with the idea of writing one. Thankfully, now, as I look at the manuscript in front of me, I do not have to.

Restlet in Action by Jérôme et al. is exactly the broad, deep, and example-driven book I had hoped for. The list of topics they tackle is impressive. The authors provide thorough but not overwhelming coverage of REST itself, security, and performance. Beyond that, they also discuss issues of growing interest such as mobile applications, the cloud, the Semantic Web, Linked Data, and the future of HTTP. The whole endeavor is grounded in practical advice on how to use Restlet toward those ends. These ideas are a Big Deal and this book will help you understand why and how to benefit from them.

I have already preordered Restlet in Action for many of my clients and students and anticipate it being a staple in my courses for years to come.

BRIAN SLETTEN
PRESIDENT
BOSATSU CONSULTING, INC.