Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

The real value of REST: Making the leap

Jimmy Bogard | Aug. 21, 2015
REST is not an architectural style to undertake lightly. Understand the problem it solves, what gaps it covers, and decide if it's right for your architecture

The real value of REST: Making the leap

One of the more reviled, misunderstood software architectures today, REST can turn a simple problem into a complicated mess. The fault lies not in the architecture itself, instead where and how it is applied. As REST at its core is simply a description of the architecture of the web, its ultimate merit can be seen seeing how far the Web has scaled through its explosive growth.

Like many new ideas or concepts, it takes many iterations of applying that concept in a variety of areas and scenarios before its true areas of applicability emerge. In the first wave of enthusiasm, developers focused on simply escaping the complication of SOAP-based Web services in favor for lighter frameworks and protocols. Today, most Web services labeled "RESTful" do not follow the constraints laid out by the original definition of REST, but the term has become so widely used to describe generic Web services that its original term has lost all meaning.

Instead of arguing about whether an API is RESTful or not, it's more valuable to focus on the original constraints and the problems REST is intended to solve. Most Web services expose capabilities through JSON-based endpoints, returning data in a format easily consumed by Javascript-based client libraries:

GET /movies/12345

200 OK
{
  title: "The Godfather"
  releaseYear: 1972
  director: "Francis Ford Coppola"
  actors: [ ... ]
}

For the vast majority of Web service-driven applications, this level of detail is sufficient to build a functional, maintainable, and resilient application. This is because of the nature of how most Web applications are developed that take advantage of Web services. For Web services intended to be used solely inside a single application, where the API is developed inside the same source control repository, there is little need for the level of decoupling that all the REST constraints provide.

Change arises

Let's consider for a moment a client that is not owned by the same developers that expose a Web service. This team wants to expose capabilities for others to consume, but want to do so in such a way that remains resilient in the face of change. For vanilla Web services, this normally brings up the topic of versioning. In the previous example, suppose we want to add new information to our response, such as who produced the film, its box office draw, additional cast and crew. This sort of change could be accomplished by adding new fields, something nearly all clients could accept without breaking. What about modifying capabilities? Instead of a single director, we allow multiple directors?

 

1  2  Next Page 

Sign up for Computerworld eNewsletters.