REST and BACK End API

 To understand the concept and operation of a REST API, picture a library with books, a librarian, and customers who wish to check out, add, update, or remove any number of books. The clients are on one side of this. This is the online application, mobile application, smartwatch, doorbell, or any other interface that uses data access. The data storage, which is usually a database or database server or some other kind of server, is on the opposite side. Our librarian, the REST API, is positioned in the center, receiving, handling, and processing requests and responses. This is how the library operates.

When the client sends a request—in this case, to retrieve a resource—the REST API receives it, locates the resource requested, determines what information must be obtained and in what format, builds a representation of the data that complies with the request, bundles it with the response header that contains metadata—such as the resource ID—and hyperlinks to actions that are available. It also includes information about the media formats this response was sent in, when it was sent, and other details. Finally, it sends the entire response back to the client. While the REST API waits patiently for the next request, the client receives the data and parses it into something useful on its end. Next, the user—or rather, the client—wants to make a change.

While the REST API waits patiently for the next request, the client receives the data and parses it into something useful on its end. Next, the user—or rather, the client—wants to make a change. After making these adjustments, the original response's content is received and sent back as a put request with the original ID. After receiving the request, the REST API interprets it as a put request for an already-existing resource, logs the requested media format, locates the resource, converts the requested data into a format compatible with the data store, submits the changes, and returns the updated resource representation and a success message to the client, informing them that everything went according to plan.
One client is making calls to the REST API in this example. The librarian will be quite busy because most apps will have several, perhaps hundreds, thousands, or even millions of clients submitting requests. However, the real flow is the same. The request is made by the client, which is then received by the REST API, which collects, processes, and provides the data along with the response header to the client.
REST API: What is it?
- The terms Application Programming Interface (API) and Representational State Transfer (REST) are synonyms. REST APIs are becoming a standard component of all web development and are essential to the creation of web applications. Knowing the true meaning of these terms—representational state transfer and application programming interface—is the first step in comprehending what they are and how they operate. Representational State Transfer, or REST, is a set of software architecture design restrictions that result in scalable, dependable, and effective systems, according to MDN.

 Therefore, REST is not a particular technology; rather, it is a data architecture and design methodology that, in exchange for a set of standard methods known as verbs, returns standardized structured data, termed the resource, which is usually JSON or XML. This methodology results in predictable and consistent outputs and behaviors. The term "representational state transfer" accurately describes the situation. We switch between state representations, and the application and the server alter these representations in between. Take a look at a common website to help you understand this.