REST is a type of software architecture that was designed to ensure interoperability between different Internet computer systems. Basically the idea is that services that comply with REST architecture can more easily communicate with one another.
REST stands for representational state transfer and it was proposed by computer scientist Roy Fielding’s 2000 PhD thesis, Architectural Styles and the Design of Network-based Software Architectures, in which he introduced and described REST.
What is REST and why should I learn more about it?
The goal of REST is to increase performance, scalability, simplicity, modifiability, visibility, portability, and reliability. This is achieved through following REST principles such as a client–server architecture, statelessness, cacheability, use of a layered system, support for code on demand, and using a uniform interface.
You can have access to the complete original Roy Fielding’s 2000 PhD thesis here: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Who is Roy Fielding?
Dr. Fielding was deeply involved in the web’s early development and standardization, he began working at and for the World Wide Web Consortium in 1994 and co-authored the HTTP 1.0 specification. Later he was the main author behind the HTTP 1.1 and URI specs also co-founded the Apache web server project.
The name “Representational State Transfer” is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
Fielding’s approach was to make sure that the REST architectural style emphasises the scalability of interactions between components, uniform interfaces, independent deployment of components, and the creation of a layered architecture to facilitate caching components to reduce user-perceived latency, enforce security, and encapsulate legacy systems.
Are there rules on how to implement REST?
REST does not enforce any rule regarding how it should be implemented at lower level, it just put high level design guidelines and leaves you to think of your own implementation. What we do have is the definition of 6 architectural constraints which make any web service – a true RESTful API.
- Client–server: By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
- Stateless: Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
- Cacheable: Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
- Uniform interface: By applying the software engineering principle of generality to the component interface, the overall system architecture is simplified and the visibility of interactions is improved. In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
- Layered system: The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
Code on demand (optional): REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented.
Did you know you can easily use REST functionality with almost no code required?
The REST Debugger is the Embarcadero free solution for exploring, understanding, and integrating RESTful web services with Delphi and C++Builder app and can be downloaded from this link
The Embarcadero REST Debugger empowers developers to explore, test, and ultimately understand how a RESTful web service works. Dive right into REST data with filterable JSON blobs, streamlined OAuth 1.0/2.0 authentication, and configurable request/resource parameters.
Once you perform validation tests using the REST debugger tool you can directly copy and paste REST components from the REST Debugger into the RAD Studio, Delphi or C++Builder IDE. This enables configuration and consumption of REST services in Delphi or C++Builder apps with just a few clicks!
Check on this video available at Embarcadero’s channel on Youtube showing more information about REST and REST Debugger.
For more articles about REST click on this dynamic search link: https://blogs.embarcadero.com/?s=REST