The article, “REST vs. RESTful: The Difference and Why the Difference Doesn’t Matter,” examines the Representational State Transfer pattern, or REST, and its implementations, RESTful services. The author, Eric Goebelbecker, mentions REST pattern’s creator Roy Fielding, and provides a link to Fielding’s dissertation.
The article then defines REST’s architectural constraints. Client-server architectural style, separating responsibilities between client-side and server-side. Client-side will handle user interaction while server-side will handle data and state. This allows for the two sides to evolve independently of each other. Stateless, the server is not responsible for a client’s session state and instead, the client keeps the session state. Cacheable, the server must classify their responses as cacheable or not. This improves performance by allowing the client to store cacheable responses for later, equal requests. Uniform Interface, possibly the most important constraint, requires the use of a uniform interface for components. This simplifies the architecture by taking advantage of the software principle of generality. The final constraint mentioned in the article is a layered system. A layered system is a hierarchical system that encapsulates components to layers that can be independent of each other. This can be used for security and performance such as load-balancing. These five architecture constraints are what defines the REST pattern.
The article then gives an example between remote procedures calls (RPC) and REST. The difference being that RPC manipulate data by remote calling the server functions and REST, instead, shares the data between client-server. Put simply, in REST the URIs work with data and not remote methods.
The article then mentions the Richardson Maturity Model. Richardson’s model classifies RESTful services into four levels of compliance. Level 0, the use of RPCs. Level 1, sharing resources between server and client. Level 2, the proper use of HTTP verbs. And level 3, exporting hypertext with objects to aid with API discoverability. The author of the article brings up that Fielding would only consider level 3 to be true REST.
Before I read through this article, I had only a rudimentary understanding of the REST pattern (I had missed the class that introduced it). I now understand REST and RESTful, the architectural pattern and its implementations. REST focuses on data sharing and a uniform interface to make its data the emphasis of the pattern and not its specific implementations. This allows for easier understanding with generality and assists with scalability.
I read some of Fielding’s dissertation and highly recommend it to anybody who is learning REST. The descriptions of the architectural constraints are clear and provide simple examples.
Fielding’s Dissertation: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm