REST Full API

In this blog, I’ll share what I’ve learned about RESTful API as well as what I’ve learned from my own personal experience.

RESTful web services are intended for use on the internet. REST is an architectural style that sets limitations, such as a uniform interface, that when applied to a web service result in desired properties like performance, scalability, and modifiability, allowing services to run efficiently on the Web. Because data and functionality are available via Uniform Resource Identifiers (URIs), which are frequently Web links, they are considered resources in the REST architectural style. To act on the resources, a series of simple, well-defined operations can be used. The REST architectural style is used to create a client/server architecture that uses a stateless communication protocol like HTTP. In the REST architectural approach, clients and servers exchange resource representations via a standardized interface and protocol.

A web service is a well-defined method of linking web-based applications over the internet using open standards like SOAP, WSDL, and UDDI. Web services allow data to be exchanged or communicated between software applications written in a variety of programming languages and running on multiple platforms.

Web services that use the REST architectural style are known as RESTful Web Services. These web services use HTTP methods to implement the REST concept (POST, GET, PUT, DELETE, OPTIONS). It gives resources a URI (Uniform Resource Identifier) and other resource forms including XML, text, and JSON.

HTTP Methods

The following are the HTTP methods that are typically used in REST-based architecture,

• GET - It provides a read only access to a resource
• PUT - It creates a new resource or update/replace an existing resource
• POST - It updates an existing resource or create a new resource
• DELETE - It delete the resources
• HEAD - It gets the response status and HTTP header information without message body
• OPTIONS - It gets the supported operations on a resource
• PATCH - Update the Resources

RESTful Services Constraints

The six architectural constraints of REST APIs

1. Client-server architecture
2. Stateless
3. Uniform Interface
4. Layered system
5. Cacheable
6. Code on Demand

Client-server architecture - the purpose of an API is to connect two pieces of software without limiting their capabilities. One of REST’s main constraints is that the client (which makes requests) and the server (which responds) must remain separate and autonomous. The client and server can upgrade and evolve in opposite directions without affecting the data interchange quality. This is especially significant in situations where a server must serve many diverse clients. Consider weather APIs: they must convey data from a single database to many distinct clients (all types of mobile devices are ideal examples).

Uniform Interface - The four operations needed to create, read, update, and delete resources are PUT, GET, POST, and DELETE. PUT creates a new resource, which may then be deleted with DELETE. The GET function retrieves a resource’s status in some form. POST changes a resource’s state. See Responding to HTTP Methods and Requests for more information.

Stateless -It means that all the state needed to handle the request is contained within the request itself, and the server does not store any session data. Whether through query params, headers, or the URI, the client must provide all information required by the server to fulfil the request in REST. Statelessness enables for improved availability because the server does not have to maintain, update, or broadcast the session state. The breadth of network optimization is decreased when a client must transport too much data to the server, and more bandwidth is necessary.

Client-server -REST applications require a client-server architecture. A client seeks resources but is uninterested about data storage, which each server handles internally, whereas a server stores resources but is indifferent about the user interface or user state. They can grow on their own. The client does not need to know about business logic, and the server does not need to know about the frontend user interface.

Layered System -An application architecture must have multiple layers. Between the client and the end server, there are multiple intermediary servers, each of which is unaware of the others except the present one. Intermediary servers can improve system availability by supporting load balancing and providing shared caches.

Code on demand - The idea is to send code or applets through the API and use them in the application. As you might expect, unknown code from a dodgy source could cause some havoc, therefore this restriction is best reserved for internal APIs where you have fewer concerns about hackers and bad actors. Another disadvantage is that the code must be written in the application’s suitable programming language, which isn’t always the case. The “Code on demand” can assist clients in implementing their own features on the fly, requiring less effort on the API or server. It enables the entire system to be more scalable and agile.

HTTP response status codes

HTTP response status codes show whether a particular HTTP request was completed successfully. The responses are divided into five categories:

1. Informational responses (100 - 199)
2. Successful responses (200 - 299)
3. Redirection messages (300 - 399)
4. Client error responses (400 - 499)
5. Server error responses (500 - 599)

REST Advantages -

• It is usually simple to build and adapt
• Process instances are created explicitly
• The client doesn’t need any routing information with the first URI.
• Client can have a generic “listener” interface for notifications
• Low use of resources

REST Disadvantages -

• Because there is no contract between the service and the client, information must be given by other ways, such as documentation or emails.
• Asynchronous calls are not possible because it uses HTTP.
• Sessions can’t be maintained.

Please add your comments if you enjoyed this article too 👍.