Dynamic Web Development with Seaside

Buy PDF Buy Print

24.1REST in a Nutshell

REST (Representational State Transfer) refers to an architectural model for the design of web services. It was defined by Roy Fielding in his dissertation on Architectural Styles and the Design of Network-based Software Architectures. The REST architecture is based on the following simple ideas:

  • REST uses URIs to refer to and to access resources.
  • REST is built on top of the stateless HTTP 1.1 protocol.
  • REST uses HTTP commands to define operations.

This last point is essential in REST architecture. HTTP commands have precise semantics:

  • GET lists or retrieves a resource at a given URI.
  • PUT replaces or updates a resource at a given URI.
  • POST creates a resources at a given URI.
  • DELETE removes the resources at a given URI.

Seaside takes a different approach by default: Seaside generates URIs automatically, Seaside keeps state on the server, and Seaside does not interact well with HTTP commands. While the approach of Seaside simplifies a lot of things in web development, sometimes it is necessary to play with the rules. REST is used by a large number of web products and adhering to the REST standard might increase the usability of an application.

REST applications with Seaside can take two shapes: The first approach creates or extends the interoperability of an existing application by adding a REST API. Web browsers and other client applications can (programmatically) access the functionality and data of an application server, see Figure 155.

First architecture: adding REST to an existing application.

A second approach consists of using REST as the back-end of an application and make it a fundamental element of its architecture. All objects are exposed via REST services to potential clients as well as to the other parts of the application such as its Seaside user-interface, see Figure 156.

Second architecture:  REST centric core.

This second approach offers a low coupling and eases deployment. Load-balacing and fail-over mechanisms can easily be put in place and the application can be distributed over multiple machines.

With Seaside and its Rest package you can implement both architectures. In this chapter we are going to look at the first example only, that is we will extend an existing application with a REST API.

Copyright © 27 February 2017 Stéphane Ducasse, Lukas Renggli, C. David Shaffer, Rick Zaccone
This book is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 license.

This book is published using Seaside, Magritte and the Pier book publishing engine.