Introduction

Hello there, my avid learner friend,

Today we will start a 4 part series on APIs. What are they all about? And is it that easy to comprehend? Yes, it is pretty straightforward.

So as not to throw too much information at you at once, I have chosen to break it up into a series with four posts. In today’s post, we will look at the basics of it all. ReSTful Web APIs are actually very easy to do. Initially, it may look like a huge mountain, but by the time we finish, it will seem like an ant hill. I am not an expert on the subject, so feel free to contribute in the comment section below.

Terminologies

First of all, what is the deal with all of these acronyms? 

ReST: It stands for Representational State Transfer.

API: It stands for Application Programming Interface. It is kind of like a set of functions and library classes that enable you to do stuff within a programming language. APIs I am referring to here are more like web services. Together, ReSTful Web APIs also called ReSTful web services.

Another fancy acronym out there on this subject is

ROA: ReST Oriented Architecture. That is SOA (Service Oriented Architecture) using ReST services

Components of a ReST architecture

Resources:

Resources are identified in requests and are separate from the representations. They are sources of specific information.

A web of resources: a single resource should not have so many details instead it should have links to or ways of referencing additional information.

Parts of a resource:

1. The URI.

For example http://agbenu.com/resources/

1. The Internet media type. That is MIME (Multipurpose Internet Mail Extension) type.

For example Content-Type: text/xml for  XML

                     Content-Type: application/json for JSON or otherwise.

1. The request method

This could be POST, GET, DELETE, or PUT.

Stateless:

Each connection is stateless. That is each new request should carry all the information needed to complete it and not rely on a prior interaction.

Cacheable:

Resources should have an expiration date and time.

Let me digress a little and give 2 points why I prefer ROA over SOAP-based SOA.

1. Easy to implement: If you have implemented SOAP, you will know what I mean. SOA has so much stuff when really all you might want to do, in some instances, is to read the value of an entity.
2. Lightweight approach: What is sent via HTTP requests is a relatively simply constructed query and not a huge bunch of XML stuff. Yeah, it’s really as light as a feather. OK, that is enough of the diversion.

There are 2 sides to the ReSTful Web API. And Einstein (yeah that’s you), before you go get any funny ideas, the 2 sides here are obviously the Server and the Client (since this is the web).

Conclusion

We will wrap it here for now. In the next post, we will get into how they make calls to each other and what they are saying in these calls.

Until we meet again later, keep learning.

Cheers!