REST stands for Representational State Transfer, API for Application Programming Interface. What is meant by this is a programming interface that is based on the paradigms and behavior of the World Wide Web (WWW) and describes an approach for communication between client and server in networks. The architectural approach known as REST (or ReST) describes how distributed systems can communicate with each other. A REST API represents an alternative to other interfaces, such as SOAP or WSDL. However, REST itself is neither a protocol nor a standard. However, architecture implementations characterized as “RESTful” use standardized processes such as HTTP/S, URI, JSON, or XML.
Roy Fielding developed the concept parallel to HTTP 1.1. He presented it in his 2000 dissertation “Architectural Styles and the Design of Network-based Software Architectures.” Accordingly, it is not surprising that the World Wide Web already provides a large part of the infrastructure required for REST and numerous web services are REST-compliant per se. This includes, for example, online services that offer static page content via HTTP. For machine processing, servers often do not deliver information like an HTML document or JPEG image. Still, via JSON (JavaScript Object Notation) or XML – the formats represent the original raw data and do not necessarily have to be the same as their format.
Six Architectural Principles
REST does not specify in detail how conforming services are implemented in fact. Instead, the approach requires the following six architectural principles (“constraints” ):
- Client-server model: REST requires a client-server model, i.e., it wants to separate the user interface from data storage. On the one hand, this should make it easier for clients to be ported to different platforms; On the other hand, simplified server components should scale particularly well.
- Statelessness: The client and server must communicate with each other in a stateless manner. That means: Every request from a client contains all the information that a server needs; Servers themselves cannot access any saved context. This constraint improves visibility, reliability, and scalability. For this, however, REST accepts disadvantages in network performance; moreover, servers lose control over the consistent behavior of the client app.
- Caching: To improve network efficiency, clients can also save responses sent by the server and use them again later for similar requests. The information must be marked as “cacheable” or “non-cacheable” accordingly. The advantages of more responsive applications with higher efficiency and scalability are bought with the risk that clients fall back on outdated data from the cache.
- Uniform interface: The components of RESTful services share a uniform, familiar interface decoupled from the implemented service. The overall goal is a simplified architecture and increased visibility of interactions. In return, one accepts poorer efficiency if the information is brought into a standardized format – and not adapted for the needs of unique applications.
- Layered System: REST relies on multi-layered, hierarchical systems (“Layered System”) – each component can only see directly adjacent layers. This allows legacy applications to be encapsulated, for example. Intermediaries acting as load balancers can also improve scalability. The disadvantages of this constraint are additional overhead and increased latencies.
- Code-On-Demand: This constraint requires that clients’ functions can be expanded via reloadable and executable program parts – for example, in the form of applets or scripts. However, this condition can be disabled as an optional constraint in specific contexts.
Implementation Via HTTP
In practice, the REST paradigm is preferably implemented using HTTP/S. Services are addressed via URL/URI. The HTTP methods (GET, POST, PUT,…) specify which operation a service should perform.
Get | Mail | Patch | Delete – Rest In Practice
Since the World Wide Web already provides the infrastructure required for REST, you can already make the first steps with the appropriate interfaces using a browser. The Fake Online REST API for Testing and Prototyping, available at jsonplaceholder.typicode.com/, provides a possible entry point for this. The solution allows access to several related data sets. After the slash, the desired resource and parameters are appended to the URL. The resources offered include 100 posts, 500 comments, 100 albums, 5,000 photos, 200 to-do lists, and ten users. The supported HTTP methods are:
- GET – requests data from the server
- POST – transmits data to the server
- PUT/PATCH – change existing data on the server
- DELETE – deletes existing data on the server
Users cannot change or delete data via the REST API for demo purposes. The server lets the corresponding requirements run into nothing – so those interested can try around to their heart’s content and don’t have to worry about breaking something in the process. So there is little reason not to start the web browser of your choice in good spirits and request data from a server via GET – that’s what happens when you enter a URL in the address bar and receive a website in return. But if you now ask jsonplaceholder.typicode.com/posts for data, the offer already provides a fairly comprehensive list of fictitious posts. Incidentally, the unappealing JSON data can be displayed with the Firefox browser: collapsible and formatted in color.
The API Development Environment (ADE) Postman offers even more possibilities. The tool runs on various platforms (Windows, macOS, Linux, and ChromeOS) and can be used free of charge in the entry-level version. As with the browser, Postman has an address bar that can be used to request data via URL. Unlike the browsers mentioned above, the software is, of course, wholly designed as a development environment and offers significantly more extensive possibilities for data manipulation. But one by one. With Postman, it is also a good idea to first enter the request previously sent via the browser. The GET method shown on the left is active by default; a click on Send provides the requested list at the bottom of the screen. Postman formats them on request – besides pure text, the program also knows JSON, XML, and HTML formats.
In addition, users can find out details about the server status, the duration of the query, and the size of the received document. In addition, the tool also displays transmitted cookies and headers. You can further refine the query if you click on the Params button to the right of the address bar. If you use the key “UserId” as the key and the value “3” as the value, the following query only returns the contributions of user “3”. It is also possible to find out who is behind this meaningless number: The question for this, which has already been supplemented with the corresponding parameter and can therefore also be used for web browsers, is jsonplaceholder.typicode.com/users?id=3 and returns the data record of a certain “Clementine Belly.
With the inappropriate username “Samantha.” If we wanted to change this, PATCH would be the method of choice., correspondingly adapted parameters deliver the following PATCH request: http://jsonplaceholder.typicode.com/users?id=3&username=Clementine – however, this acknowledges the Fake API with status 404; The same thing happens when you try to delete the dataset with Delete. Lastly, REST APIs can also be controlled directly via code. For example, we chose PHP to connect to the server via the cURL library and look for posts from the now-familiar user number 3, Clementine. The returned data is converted to a corresponding array via json_decode and output.
Also Read: THE ALTERNATIVES TO GOOGLE ANALYTICS