Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Herndon. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is an Appian, Pegasystems, and UIPath Low-code and RPA Value Added Service Partner. You can reach him at [email protected].
You may have come across the debate on the best way of implementing communication between applications in Enterprise Scale Networks. The current mainstream mainly uses SOAP (Simple Object Access Protocol) and WSDL (Web Service Definition Language) for the exchange of structured information in computer networks. However, more and more enterprise development is now changing to REST (REpresentational State Transfer).
What is REST? REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server. We will go into what these terms mean and why they are beneficial in this blog.
In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other. This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.
As long as each side knows what format of messages to send to the other, they can be kept modular and separate. Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. Additionally, the separation allows each component the ability to evolve independently.
History of REST 
The term REST was initially defined in a Ph.D. thesis by Roy T. Fielding in 2000. Roy was among the primary designers of most Web protocols, including URLs and HTTP. In his dissertation, Roy defined a methodology of describing architectural styles, which are high-level abstract patterns expressing the core ideas of an architectural approach. Some of the architectural styles in the dissertation include distributed objects, client/server, ‘’null style,’’ and REST. REST or (REpresentational State Transfer) is a high-level architectural style that you can implement using different technologies and instantiate using diverse values for its abstract elements.
REST is an architectural style designed for distributed systems. These systems provide users with logically transparent access to mixed hypermedia information repositories distributed across wide and local area networks. Like all other architectural styles, REST has its guiding constraints that must be fulfilled for an interface to be considered RESTful.
Before considering the principles of REST, there are two key terms you should keep in mind. First, the client is a software or person that consumes the REST API. Second, the resource is any object on which an API can provide information. Every resource comes with a distinctive identifier that can be a number or name. When writing something on Twitter, for instance, your browser calls the Twitter API that uses the returned data to generate information on a screen. Conversely, a resource on Instagram can be a hashtag, photo, or user.
RESTful applications expose information about themselves as information on their resources. They also enable clients to conduct actions on these resources, including creating new resources and changing existing ones.
Here is a diagram summarizing these principles and some information on what they entail.
uniform interface
The overall system architecture of the software is simplified by applying the engineering principle of generality. This also improves the visibility of interactions. To get a uniform interface, several architectural constraints are used to guide the components’ behavior. Four regulations define REST. These include self-descriptive messages, hypermedia, the use of representations for resource manipulation, and resource identification.
With a uniform interface, a client can communicate with a server in one language irrespective of the architectural backend of the client or server. This means you have standardized communication between clients and servers.
Stateless
The APIs used in REST are stateless. This means that calls are made independently, and they all have the necessary data to complete themselves successfully. REST does not rely on the data stored on sessions or servers to determine how a call should be handled but instead solely on the data that the call itself provides.
The identifying information will not be stored on a server when a call is made. Each call contains its identifying information like user ID, access token, and API key. Being stateless increases the reliability of REST since all the necessary data is readily available to make calls. To make RESTful API as scalable as possible and reduce memory requirements, all states are stored on the client rather than the server.
cacheable
Since the REST API is stateless, you might deal with an increased request overhead when handling a lot of outbound and incoming calls. To prevent this, the architectural style encourages cacheable data. This means that your data will indicate its expiry date or, if you need real-time data, it indicates that a client should not cache the data.
With cacheable data, you will significantly reduce the interaction numbers with your REST API, decrease internal server use and give users the necessary tools for the most efficient apps. However, remember that caching is only done on the client’s side. Though you can store some data within your API architecture to improve overall performance, your intent is instructing a client on whether or not he/she can cache the data temporarily.
client-server
We discussed this at the open, but it is worth repeating, as it is a constraint…
This constraint is based on the concept that the server and the client should be separated and allowed to evolve independently. Simply put, you should be able to alter your client applications without affecting your server’s database design or data structure. Conversely, you can modify your database with no effect on the client application. By separating your data storage and user interface concerns, you improve the user interface’s portability across multiple platforms while improving the scalability of your server.
layered system
The REST API comprises hierarchical layers with different responsibilities and functionalities. Though separate, each of the layers interacts to create a modular and scalable application. Layered systems allow you to move elements in and out of REST as services and technologies evolve. You also have several security benefits with a layered system. As an example, it will enable you to curb attacks at your proxy layer before hackers can get to the actual server architecture.
code on demand
This allows code to be transmitted via the REST API for use within your application. In essence, the code on demand constraint creates a smart application that is not solely dependent on its code structure. It thus reduces the features that need re-implementation to ease a client’s work.
how does rest work
REST, as you have already discovered, is a series of architectural constraints rather than a standard or protocol. Developers can implement it in several ways. Nonetheless, the implementation generally follows the same routine. When a client makes a request via RESTful API, a representation of the resource is transferred to the endpoint or requester.
The representation or information is delivered via HTTP in plain text, PHP, Python, HTML, JSON, or XLT. JSON {JavaScript Object Notation} is the most commonly used programming language because it is readable by both machines and humans. The parameters and headers of a request are also crucial in the HTTP delivery of a RESTful request. This is because they contain the crucial identifiers on the request’s authorization, caching, cookies, metadata, and more.
In REST API, a transaction is broken down into modules, each addressing particular underlying components. The request uses the HTTP methodologies described in the RFC 2616 protocol. This means GET retrieves a resource, PUT updates or changes the state of a resource, and POST creates the resource while DELETE removes it.Here is an outline of the REST process. These are what as know as the HTTP Verbs. Learn more here, what is CRUD.
So very simply, in the REST architecture, clients send requests to retrieve or modify resources, and servers send responses to these requests. Let’s take a look at the standard ways to make requests and send responses.
For each HTTP verb, there are expected status codes a server should return upon success:
- GET — return 200 (OK)
- POST — return 201 (CREATED)
- PUT — return 200 (OK)
- DELETE — return 204 (NO CONTENT) If the operation fails, return the most specific status code possible corresponding to the problem that was encountered.
Below is a simple figure representing the REQUEST/RESPONSE FLOW…
OK, I can hear you saying how does this work in SAP ABAP? Well first PI/PO does have a REST adapter and you can code RESTFul API’s in ABAP. Please read this post from SAP as far back as 2013 for some thoughts and then start learning if this is new to you. You cam read our 5 past Blog blog on ABAP 7.4 for the latest ABAP syntax starting with New Features in ABAP 7.4 – Database Access – ITPFED.
Differences between SOAP and REST
When talking about APIs, the most common architectures you will come across are REST and SOAP. Though these are usually compared as apples to apples, the two are different technologies. To start with, REST is an architectural style, while SOAP is a protocol. REST can use the SOAP protocol to process requests in the same way it uses HTTP.
REST is the best choice when you have limited resources and bandwidth. This is because SOAP messages consume more bandwidth and have a lot of content. Coding is also easier for REST than it is for SOAP, as is implementing a cache.
Here is a table on the differences between REST vs SOAP
what are the advantages of using REST
There are several benefits of using REST over other architectural styles and protocols for communication on your network. Here are a few of them.
- The interactions in REST are based on familiar constructs to everyone well-versed in HTTP, SSL, and TLS. As such, developers can use this architecture style easily because they are already familiar with its elements.
- Users can access the same standard data model and objects as they would when using SOAP-based services.
- It serializes data in JSON or XML format to make development or programming flexible.
- New clients can easily work on other applications whether or not they are designed for a specific purpose.
- When creating RESTful services or APIs, developers can use any language that allows HTTP to generate web-based requests. This makes it easy to choose the technologies that best suit your needs and you prefer working with.
- REST APIs have high flexibility. This is because data is not tied to methods or resources, so you can handle several calls and return diverse data formats. In so doing, you can address the needs of different clients at the same time.
Summary
In simple words, in the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs).
The resources are acted upon by using a set of simple, well-defined operations. Also, the resources have to be decoupled from their representation so that clients can access the content in various formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others.
The clients and servers exchange representations of resources by using a standardized interface and protocol. Typically HTTP is the most used protocol, but REST does not mandate it.
Metadata about the resource is made available and used to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control.
And most importantly, every interaction with the server must be stateless.
All these principles help RESTful applications to be simple, lightweight, and fast.
