REST API

As the use of Internet grew, various technologies sprouted to develop web applications. APIs, or Application Program Interfaces were developed to enable two technologies to communicate with each other. An API is a set of programming code that enables data transmission between one software product and another. It also contains the terms of this data exchange. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API. The API specifies how you can authenticate (optional), request and receive data from the API server. The four basic ways APIs ‘call’ for information from an application include GET, PUT, POST and DELETE. There are different types of APIs like open / public APIs, internal / private APIs and partner APIs. Each plays a different role. However, APIs need to adhere to specifications in order to standardize data exchange between web services.

Web services are purpose-built web servers that support the needs of a site or any other web application. Client programs use APIs to communicate with web services. A web API is hence the face of a web service, directly listening and responding to client requests

Simple Object Access Protocol (SOAP)

SOAP, developed by Microsoft, is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is mostly used with enterprise web-based software to ensure high security of transmitted data.

Representational State Transfer (REST)
REST API is the new kid on the block. The term REST was introduced by computer scientist Roy Fielding in a dissertation in 2000. REST API is defined as a Software Architectural Style built to guide the development and design of the World Wide Web’s architecture. REST APIs define a set of constraints on how the architecture of a distributed system should behave. The key idea here is that REST is a style, not a protocol or standard that should be adhered to. In other words, there are no set of hard rules to follow, in order to have a RESTful architecture. REST is considered a simpler alternative to SOAP, which many developers find difficult to use as it requires adhering to strict protocols for the sake of standardization. It also requires following the XML structure for every message sent. REST makes data available as resources. Each resource is represented by a unique URL, and one can request this resource by providing its URL.

REST is protocol-independent (as long as the protocol has support for a URI scheme). An important aspect of REST is that it is an architectural style – not a guideline, not a standard, nor anything that would imply that there are a set of hard rules to follow to end up having a RESTful architecture.

RESTful systems support messaging in different formats, such as plain text, HTML, YAML, XML, and JSON, while SOAP only allows XML. The ability to support multiple formats for storing and exchanging data is one of the reasons REST is a prevailing choice for building public APIs these days.

The main idea behind REST is that a distributed system, organized RESTfully, will improve in the following areas:

Simplicity: REST is simple to learn, understand and implement. REST API is cleaner and very easy to decipher. A simple interface allows for simpler interactions between systems, and REST APIs can be developed and deployed with minimal efforts
Scalability: REST separates the client and server. A distributed system handles component interaction well, and the simple interaction afforded by REST allows for this
Flexibility: The REST API adapts at all times to the working syntax and platform by serializing data in JSON or XML format. This allows the development team to use multiple environments while developing
Portability: REST is a style of architecture. It is hence language agnostic, meaning that it can be implemented and consumed by any type of technology
Visibility and Reliability: Development teams can migrate to other servers or make all kinds of changes in the database at any time, as long as the data from each request is sent correctly. The stateless constraint proposed by REST allows for the easier recovery of a system in case of failure
Load Handling: REST APIs allow high handling of loads with the help of HTTP proxy server and cache
Independence: The separation between client and server empowers development teams to scale the API and the web application without too much problem. The REST API always adapts to the type of syntax or platforms being used, which gives considerable freedom when changing or testing new environments within the development

REST is best used where the bandwidth and resources are limited but the developers are experienced enough to implement the API properly. REST is also beneficial if there is a need for bigger cache. Currently, REST is the most popular approach to building web APIs, representing over 70% of public APIs. Its great flexibility provides more freedom to create an API as long as your architecture follows six constraints that make it truly RESTful:

Uniform interface: there must be a unified way to interact with your server. In other words, requests from different clients (for example, a mobile app and a website) will look similar. One resource in your system must have a single name, called Uniform Resource Identifier, that will be referenced in API requests (https://my-api/users).
Statelessness: as servers store no information about previous interactions, each API request should provide the necessary context.
Separation of concerns: the app’s backend should be developed independently from its user interface.
Caching of responses: servers should inform clients whether the response can be stored in cache.
Multiple communication layers between the server and the client.
Code on request: if requested, API responses might include executable code.

Challenges in using REST
With greater freedom comes greater responsibility. REST is stateless, but most web applications require stateful mechanisms. Developers need to handle this properly. REST doesn’t impose strict security like SOAP. That is why REST is appropriate for public URLs, but is not recommended for transferring data between a client and server or for web applications where security is a paramount consideration.