A REST

Representational State Transfer (REST) is an approach to designing distributed architectures. Here, a distributed architecture means parts of the program run on different machines and communicate over a network. Think of a web application where a browser talks to a web server, or an application for exchanging data between financial institutions where their servers call one another.

Roy Fielding designed and described REST in his 2000 dissertation, Architectural Styles and the Design of Network-based Software Architectures. For this discussion, the most interesting part is chapter 5, in which Fielding derives REST principles from familiar architectural approaches.

Basic REST principles

• Application state and behavior are expressed through a resource, the central abstraction.
• Each resource has a unique identifier (URL, URN).
• A uniform interface for getting and manipulating resources defines four CRUD operations (Create, Read, Update, Delete).
• A resource can have multiple representations (XML, HTML, JSON, SVG, PDF).

Communication protocol

• Client/server separates responsibilities.
• Statelessness means each request must contain all the information needed to carry it out.
• Caching. Each request can be explicitly marked cacheable or non-cacheable, so adding a cache between client and server can transparently improve performance.
• Code on demand. The server can send code, such as JavaScript, to extend client functionality.
• Layering lets you combine layers that provide services such as caching, transformation or load balancing to make the system more flexible.

There are, of course, other approaches to distributed architecture, such as Remote Procedure Call (RPC). Broadly, REST and RPC differ in two ways: the semantics of operations and what gets distributed. The operation semantics in REST are finite and consist only of CRUD (create, read, update, delete) on a given resource. In RPC, the semantics correspond to the methods being called. REST distributes state, the data represented by a resource, while RPC distributes behavior.

REST has the following advantages over RPC.

• A simple interface that is resilient to change and easy to extend.
• Little burden on the client to understand the meaning of operations.
• Transparency. Resources can easily be cached, transformed and so on along the way.

REST has the following disadvantages compared with RPC.

• The client must send all the information needed to process each request.
• Middleware support is missing, so you have to write everything yourself.

The lack of middleware support is probably the biggest problem because it makes working with REST very inconvenient. There are exceptions, of course, such as Google's GData, which makes it easy to use Google services over REST. GData has client libraries for Java, JavaScript, .NET, PHP, C++ and Python.

In Java we can look forward to JSR 311, Java API for RESTful Web Services, which will hopefully make REST easier to use in Java. The reference implementation is called Jersey. You can learn about it in the interview RESTful Web Services and Jersey. I would especially recommend the JSR 311: JAX-RS presentation, which shows examples in practice.

REST will be a topic at a future CZJUG meeting, and we should talk about Jersey with one of its authors in an upcoming podcast. To finish, here are a few interesting links.

• Data-Driven Communication vs. Behavior-Driven Communication (PowerPoint presentation)
• REST
• Building Effective Enterprise Distributed Software Systems