Web APIs - A timeline of web services (Part II)

We have web services that relay data back and forth wrapped up with the metadata only just as much as needed.

That sounds fair enough!

What are these APIs?
Aren't these the documentation (manuals) for how to use any system? A system can be a database system or a bank account management system or an ERP system.

10 points to Griffindor for bravery and mainly compassion for saving us from the perils of defining the API!

Absolutely! The Shopping APIs or the Search APIs you see at Google or eBay are simply the Web Service APIs, shortly Web APIs.

Let's walk through the evolution of Web APIs.

The advent of XML eventually led to a nice protocol called SOAP. SOAP facilitated data access by wrapping data into understandable objects which are represented in an intuitive mail-like structure (imagine head, body and attachments) with a clearly defined metadata - schema.

Around 2000 and over a decade later, Web API world is taken by a Service-oriented Architecture (SOA) storm. This perspective of designing web/system architecture resulted in many advancements (Note: I'm using the term web with caution because its pervasive expansion to different devices resulted in broadening its own definition )

1. separation of concerns through layering/composing services at different granularity, 
2. security layering through OAuth and other mechanisms, 
3. service discovery through a registry (UDDI)
4. service definition and publishing standards (WSDL) in enterprise integration

to name a few.
Here's some more reference information on this.

Enterprise integration imbibed elements from SOA standards. WS-I OASIS and metro stack operationalized some standards defined and advocated by SOA working groups. The gamut of services and the complexity in defining an overarching integration framework resulted in exploring simpler components for integration. SOA (though it sustains) needed to uncomplicate.

A RESTful Architecture fills-in some of the short-comings of SOA.


Continued in the next part...

(Please let me know your feedback in the comments.)

Web APIs - A timeline of web services (Part I)

Let me start from: How do we access data from a remote system?

In the world of connected systems, where there are all kinds of possible message exchange systems, talk about peer-to-peer, electromagnetic waves (radio, IR and all other types), bluetooth, wifi, there are numerous possibilities of how we can exchange messages with other systems.

As a message exchange standard across www, HTTP stands out as the most used. HTTP stood the test of time and scale! It has perpetuated decades of internet revolution while evolving to fit the needs of computing infrastructure and message exchange.


Web page:

Message exchange over a period of time became synonymous to web page request and response paradigm.

Here's a URL: https://google.com

And the server responds with a beautiful web page which satisfies all your urges for knowledge and wisdom!
This is how most internet services came into existence.
Seek (GET) what you need.
Wait... Are you registered? Sign up (POST).
Only then you see your data!

Session Handling:

Our needs went beyond the request-response (question-answer) style. By nature, we need more than an exchange of information - the context. This is when this miraculous state-saving/state-tracking/state-persisting technology came into existence.


Web Services and web APIs

While the world is happy with the life's answers to our needs through web pages, users asked the providers, "Do I need the overhead of your styles and showmanship when what I am actually using is the fields... only the fields I'm interested in?"

That's when the providers started thinking "Why do I need to have this guy's session on my page? I'm doing so much to keep him happy on the page with all my wooing experience! And still he/she is just happy with the fields".

A superb semantic medium called XML got the users and the providers on the same page

I need
<datafield1>value1<datafield1>
<datafield2>value2<datafield2>

And this is definitely more than what we need
<html>
<head>
<link...>
<link...>
<script...>
</head>
<div>datafield1</div>
<div>value1</div>

<div>datafield2</div>

<div>value2</div>

<body></body>
</html>

When the user doesn't need to stay logged in to their session, the server does not need to do session handling!

1. More time for server. Less processing because of no session handling and asset manipulation. 
2. Faster turnaround. Avoid context switching overhead. 

Question: How is it possible? 

Answer: A web service! 

You want to search products using a keyword.

http://www.mysampletesturl.com/search?keywords=smart,phone

And pat comes a result:

<products>

<product>

<id>123</id>

<name>iPhone</name>

<description>coolest of smart phones is here!</description>

</product>

<product>

<id>124</id>

<name>LG Nexus 6</name>

<description>Another coolest of smart phones is here!</description>

</product>

</products>

But this still happens over HTTP! What's the big deal? 

OK, we don't have to process all the additional display components (scripts, heads and bodies). I give it to you! 

What more? 

Continued in the next part...

(Please let me know your feedback in the comments.)