Ipaas

Middleware has been around for as long as I can remember and it seems to have been first used as far back as 1968.

The term middleware was used in the famous report  of the 1968 NATO Software Engineering Conference:
  

Middle wear in reference to distributed computing sits on top of the tcp/ip protocol stack

Advanced REST scenarios

REST complex objects 

There are two approaches to managing complex objects in REST where we can include the entire object in its operation and/or provide specific paths for each object 

Invoice creation as a whole object

POST /invoice 
{
"invoiceId": 1000,
"invoiceDate": "02/04/2001",
"vendorName": "XYZ Industries Ltd",
"approving Manager": null,
"accountNumber": null
 "address":{
  "streetName":"123 St Kilda Road",
  "suburb": "St Kilda",
  "state":"VIC",
  "postcode":3000
 }
}

Create the subobjects on their own like below 

POST /invoice/1000/address

 "address":{

  "streetName":"123 St Kilda Road",

  "suburb": "St Kilda",
  "state":"VIC",

  "postcode":3000

 }

REST managing state 

Managing the state in REST can be quite challenging. The change in state may trigger different validation and business rules used to process that payload. Rather than using complex logic we could use the resource paths to model the representation of each state. 

Example 

Modifying the pre-approval and post-approval of a workflow item. Below is an invoice that requires approval for payment. 

Invoice creation state 

POST /invoice 
{
"invoiceId": 1000,
"invoiceDate": "02/04/2001",
"vendorName": "XYZ Industries Ltd",
"approving Manager": null,
"accountNumber": null
}

Invoice approval state

PUT /invoice/1000/approval 
{
"invoiceDate": "02/04/2001",
"vendorName": "XYZ Industries Ltd",
"approving Manager": "Tom",
"accountNumber": null
}
   
Invoice payment state

PUT /invoice/1000/payment 
{
"invoiceDate": "02/04/2001",
"vendorName": "XYZ Industries Ltd",
"approving Manager": "Tom",
"accountNumber": 6597465923056
}

Everything RESTful

REST is a lightweight web service and stands for Representational State Transfer. REST uses the HTTP protocol to model and implement these web services. In its ideology, it aims to manipulate resources in a stateless fashion using the HTTP methods GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS and TRACE.

History 

Roy Fielding defined REST in 2000 as part of his Ph.D. dissertation "Architectural Styles and the Design of Network-based Software Architectures" at UC Irvine.^[3]


Prerequisites 

In order to understand how REST works you must have a good understanding of the underlying HTTP protocol works.

HTTP protocol consists of a REQUEST and RESPONSE sequence

Both REQUEST and RESPONSE are made up of a header and body. 

header - consists of metadata modeled as key-value pairs. Header data consists of information such as the type of data, length of data, security information and so on.  Some examples of header tags Content-Type, Content-Length

body - consists of the payload which is the data to be transported. this data can be XML, JSON or just plain text. 

Understanding REST 

Below we can see how CRUD operations are implemented using REST.

a) Creating a resource 

POST method 
POST /path/myAPI

{"key":"FieldName","Value":"someValue"}

b) Retrieving a resource

GET method  

GET /path/myAPI

{"key":"FieldName","Value":"someValue"}

c) Updating a resource

PUT method 

PUT /path/myAPI

{"key":"FieldName","Value":"someValue"}

PATCH method

Below is an example of how to use PATCH and overcome the ambiguity of identifying which fields need to be modified vs those that don't.

PATCH /path/myAPI

{"key":"FieldName","Value":"someValue"}


There is a very good article from William Durand please-do-not-patch-like-an-idiot. He goes further in its use to specify various operations that can be achieved with the PATCH method. Which addresses the common design problem in a PATCH call, differentiating a request value to be set to null as opposed to using null to retain its current state. 

d) Deleting a resource 

DELETE method 

Naming conventions 

There is a preference to name resources in the plural, as they can be collections of data.

An introduction to the blog

Systems integration and distributed computing have always been a fascination since the start of my journey in the Information Technology industry. I still remember my very first attempt at hooking up two 286 machines using their serial port to talk to each other.