Table of Contents
What is REST and why should I learn more about it?
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, whether you are designing mobile apps, Linux, macOS, or purely Native Windows Development.
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.
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.
Where can I download Roy Fielding’s Original PhD thesis about REST?
You can have access to the complete original Roy Fielding’s 2000 PhD thesis here!
Since long time ago Mr. 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.
What do the different REST terminologies mean?
REST does not enforce any rule regarding how it should be implemented at lower level, it just put high level design guidelines and leave 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.
Can I really I can use REST with absolutely NO code required?
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!
Where can I learn more about how to use REST in my Delphi programs?
For articles on this blog you can click this dynamic search link: https://blogs.embarcadero.com/?s=rest
Also, check out this really great video the video below, available at Embarcadero’s channel on Youtube, which shows more information about REST and REST Debugger and how you can easily load and manipulate datasets at design time and runtime. It’s quite amazing to see this and no other system comes even close to providing this sort of easy to use but ultra-powerful capability.
You can easily create apps which work with REST servers using RAD Studio Delphi. Why not download a free trial copy today?