Overview
Representational State Transfer (REST) is an architectural style used to build distributed hypermedia systems. The World Wide Web is the best known example of such a system.
The focus of REST is on resources rather than services. A resource is a representation of an object or information. A resource can represent:
A single entity, like a coffee pot you want to purchase from an online shopping site.
A collection of entities, like records from a database.
Dynamic information, like real-time status updates from a monitoring site.
That is, resources are the entities or collections of entities in a distributed system that you want to post or retrieve or take action on. In a REST style system, each resource is identified by a universal resource identifier (URI).
Development of REST systems is defined by a series of constraints:
Clients and servers are separate.
Communication between clients and servers is stateless.
Clients can cache responses returned from servers.
There may be intermediate layers between the client and server.
Servers can supply code for the clients to execute.
Clients and servers remain loosely coupled by communicating through a uniform interface.
The uniform interface is the key constraint that differentiates REST from other architectural approaches. The characteristics of this interface are:
Requests identify resources.
Responses contain representations of those resources.
Clients manipulate resources through their representations.
Messages are self-descriptive.
The interface employs Hypermedia as the engine of application state (HATEOAS), which enables the client to find other resources referenced in the response.
One strength of REST is that it leverages the well understood methods supported by HTTP to describe what actions should be taken on a resource. To be REST-compliant, an application must support the HTTP GET, POST, PUT, PATCH, and DELETE methods. Many applications use web browsers to interact with resources on the Internet. web browsers, however, typically support only the HTTP GET and HTTP POST methods. To get around this restriction, you can use Integration Server to build REST-compliant applications that support all five methods.
Integration Server can be a REST server or a REST client. When Integration Server acts as a REST server, it hosts an application that you write. The application includes services that you write that instruct Integration Server to process some or all of the HTTP GET, POST, PUT, PATCH, and DELETE methods in request messages against resources. When Integration Server acts as a REST client, it sends specially formatted requests to the REST server.
