What is REST API?

REST or Representational State Transfer is a set of architecture constraints, not a protocol or a standard. REST relies on stateless, cacheable, and client-server communication via HTTP using the API interface which can be used from any device or operating system.

From Wikipedia - en.wikipedia.org/wiki/Representational_stat.. REST is a software architecture style that was created to guide the design and development of the architecture for the World Wide Web. A web API that obeys the REST constraints is informally described as RESTful. RESTful web APIs are typically loosely based on HTTP methods to access resources via URL-encoded parameters and the use of JSON or XML to transmit data.

The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.[1][3] The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state machine) where the user advances through the application by selecting links (e.g. example.com/articles/21), resulting in the next resource's representation (the next application state) being transferred to the client and rendered for the user.

The Web began to enter everyday use in 1993-4 when websites for general use started to become available.[4] At the time, there was only a fragmented description of the Web’s architecture and there was pressure in the industry to agree on some standard for the Web interface protocols. Together the W3C, and IETF working groups, started work on creating formal descriptions of the Web’s three primary standards: URI, HTTP, and HTML. Roy Fielding was involved in the creation of these standards (specifically HTTP 1.0 and 1.1, and URI), and during the next six years, he developed the REST architectural style, testing its constraints on the Web’s protocol standards and using it as a means to define architectural improvements — and to identify architectural mismatches. Fielding defined REST in his 2000 Ph.D. dissertation "Architectural Styles and the Design of Network-based Software Architectures" at UC Irvine.

The REST architectural style is designed for network-based applications, specifically client-server applications. But more than that, it is designed for Internet-scale usage, so the coupling between the user agent (client) and the origin server must be as lightweight (loose) as possible to facilitate large-scale adoption. This is achieved by creating a layer of abstraction on the server by defining resources that encapsulate entities (e.g. files) on the server and so hiding the underlying implementation details (file server, database, etc.). But the definition is even more general than that: any information that can be named can be a resource: an image, a database query, a temporal service (e.g. “today’s weather in London”), or even a collection of other resources. This approach allows the greatest interoperability between clients and servers in a long-lived Internet-scale environment that crosses organizational (trust) boundaries.

Clients can only access resources using URIs. In other words, the client requests a resource using a URI and the server responds with a representation of the resource. A representation of a resource is another important concept in REST; to ensure responses can be interpreted by the widest possible number of client applications a representation of the resource is sent in hypertext format. Thus, a resource is manipulated through hypertext representations transferred in messages between the clients and servers.

REST API Principles

REST is a set of design principles for building scalable web services. Roy Fielding described the following six constraints in his Ph.D. dissertation for building a RESTful architecture:

1. Uniform interface
2. Client-server
3. Stateless
4. Cache
5. Layered system

6. Code on demand

7. Works on the CLIENT-SERVER architecture where the clients use HTTP calls to communicate with the APIs

8. RESTful APIs are stateless, which means they do not account for already known information of the object that is being processed. These so-called states will never be passed between requests
9. A RESTful API has to allow for caching of often-used resources
10. RESTful APIs have a uniform way of communicating with other APIs
11. The variables are URI based and have to be identified with the URI, for example, /invoices/1/print
12. They will contain Content-type headers describing the metadata of the API

Image Source - quora.com/What-is-REST-API-and-its-advantages

HTTP Methods

A resource in RESTful is something that is accessible through HTTP which is accessed via URI (Uniform Resource Locator). A URI has two subtypes:

1. URL stands for Uniform Resource Location and specifies the network address or location where the resource is available
2. URN stands for Uniform Resource Name which is a symbolic name

A RESTful request targets a resource, but the resource itself typically is created on the service machine and remains there. The requester receives a representation of the resource if the request succeeds. It is the representation that transfers from the service machine to the requester machine.

In a REST API, a client does two things in an HTTP request:

1. Names the target resource by giving its URI, typically as part of the URL.
2. Specifies a verb (HTTP method), which indicates what the client wishes to do; for example, read an existing resource, create a new resource from scratch, edit an existing resource or delete an existing resource.

Below are HTTP methods or verbs for the requested supported