HTTP Basic Flow Overview

HTTP
Http protocol has been designed to serve and transfer information, resources across the world wide web with an architecture style (REST) which discourages bottleneck (by utilizing routers, gateways, proxys, tunneling etc), network congestion (by limiting no. of connection at a time, Connection timeout etc) and encourages Uptime and availability (using Stateless protocol, Connection close on Response),Scalability (using Stateless, Client-Server model, etc.), Uniformity (by defining a set of Methods like PUT, POST, GET, DELETE, HEAD, OPTION etc. for all and pre-defined purposes).

• It states that a client should first establish a communication channel and send an Http request. Then each Http request for a resource or information must be acknowledged with an Http Response and then the communication channel should be disconnected from the server immediately.
• It also states that an established but idle channel should be time-out and disconnected automatically.
• It also recommends that an Http Client (for e.g. a browser) should make at most 2 connections per server at any given point of time.
• Http should not be used for a stateful, client server based model where dedicated and active connections are required for communication. It should not be used where both way communications can be initiated even through an established channel, but only for pull based Request/Response flow model.

HTTP and HTTP based server push

Overview
HttpPush refers to the mechanism whereby an Http Server is able to send data to the HttpClient as and when it is available instead of waiting for client to Poll the server, thereby facilitating an http based real time notification platform. This blog discusses and showcase the available approaches for designing an Http Server Push (unlike the conventional Http Pull) based solution for a business model. This document does not make a comparative study between the different approaches as each one of them is suitable for a particular business scenario. It also discusses some finer details of Http protocols (but not all) for better understating of the protocol, the Http push approaches and its limitations. It highlights the end to end flow between an Http Client and Server for each of the approaches.
The below section is divided into two parts - HTTP Overview and Server push approaches.
Http Overview: Please follow HTTP Basic Flow Overview
Server push approaches

ShortPolling
This approach is not exactly an Http Push, but still can be used to get data in near real time from the Http Server. This is applicable for both Http1.0 and Http1.1. Typically; this is chosen when no other option is available due to some constraints on the client side programming. As the name suggest, ShortPolling is a mechanism to continuously poll the Http server. With each Http Request, the server should check if there is any new data available, then it sends the same else send a blank Http Response. HttpClient makes a next request after a delay (say 1 sec) after the HttpResponse for the previous one is received. And this goes on and on and on.

• Though with Http1.1 (Persistent Connection), it can use the same (persistent) connections for all the requests/responses, but still this is a waste of resource, time, bandwidth, network where the chances of getting new data with every request is less. This may be useful where there is chance of high data availability every second like the Stock market
• This can be useful when a server can determine the time for next availability of data and instead of sending back a blank response, it sends the (future) time for availability of new data. The next request from the client can be triggered based on the time received with the previous response.

Soap Vs Rest

SOAP (Simple Object Access Protocol) is a XML based (application to application) request/response message exchanging protocol which is use to call methods on a remote objects using the XML based messages governed by SOAP message format for method invocation. All messages, in/out types, faults as defined in the SOAP xml are actually converted, mapped and invoked to the remote object's method, arguments and responses, and exceptions respectively at the remote side. SOAP messages defines it own data types which are mapped to the corresponding Java Types or SQL type or C Types etc during the actual method invocation. This conversion between xml messages to object's methods and vice versa is a complicated process and practically needs a client and server side SOAP tools. SOAP messages can be transferred through any application level transport protocol like HTTP, FTP, SMTP etc. but HTTP is the most popular one.

REST (Representational State Transfer) is an architectural style which imposes restriction on the client-server design - like stateless communication between client and server, caching at the client server side, uniform methods etc.. REST style advocates to define everything in terms of Resources which has Representaion of its State that can be Read, Write, Updated and Deleted. Resources can be represented in any format but mostly xml or json is used. Unlike SOAP, messages in REST are not mapped to any resource specific method calls but they are just well formed (resource) information which are parsed at server side and processed as per business logic - Parsing can be done by any means like normal String parsing, SAX, DOM, Streaming parsing, JAXB parsing etc. Unlike SOAP, REST does not restrict message format or usage of tools.

Soap (Simple Object Access Protocol)	Rest (Representational State Transfer)
Strict messaging format as defined by SOAP	Free format. Mostly XML or JSON.
Operation or RPC oriented	Resource oriented
Soap Messages are basically remote method calls with arguments and exceptions and return types. Soap messages, in/out types, faults are actually converted, mapped and invoked to the remote object's method, arguments and responses, and exceptions respectively at the remote side.	Rest Messages are well formed information and are parsed using XML parsers. Sometimes messages are converted into objects.
Practically heavily dependent on SOAP based tools both at Server and Client side.	Dependency on tools are optional
Messages are machine readable.	Messages are human readable.
Messages, operations conversions are complex.	Lightweight.

Https Flow made easy

• HTTPS = HTTP + SSL
• Cryptography = Science of hiding information
• Cipher text= Message represented in secret code.
• Encryption= Process of transformation of plain text to cipher text (or encrypted text).
• Decryption= Process of transformation of cipher text (or encrypted text) to plain text.
• Cipher= Algorithm used for encryption and decryption is called Cipher algorithm.
• Symmetric key algorithm= Cipher using same key for Encryption and Decryption.
• Asymmetric key algorithm= Cipher using different key for Encryption and Decryption. Key used for encryption is called public key and key used for decryption is called private key
• Computation logic using Symmetric is lighter than Asymmetric key i.e Asymmetric is costlier than Symmetric key.