Magazines, Books and Articles

Wednesday, March 18, 2015

I was recently working on a .NET project that uses CouchDB v 1.6.1 as its database. As part of this project, I created this library to abstract away the HTTP requests to a CouchDB. It is a work in progress, but the methods available should be sufficient for CRUD operations on a CouchDB database.

Tuesday, December 2, 2014

In this post we discuss the need for versioning an API and the possible ways to do it. The need for versioning is not restricted to the REST scenario alone - whatever is applicable to the REST scenario is also applicable to HTTP web services.

APIs don't exist for themselves - they are meant to be consumed by clients. When an API is considered stable and shipped to production, a client consuming the API buys into the media type and the representation of the resources it describes. Now if the API was to undergo a change - and it will, as change is the only constant in our industry - its clients' will in all probability break.

Sunday, October 19, 2014

In this post we discuss how to design and build a REST API (a collection of REST web service).

As with any design we ask ourselves what our end goals are, and then decide how we go about achieving these. I believe the questions below set out what the minimum end goals are when designing a successful REST API.

1. How do we discover a Resource? What is its URI? How do we map HTTP methods to the actions possible in an entity?
2. What is the representation of the resource?
3. How do we decide on a contract for the services?

Answers to question 1 and 2 are necessary for designing both HTTP and REST web service; the answer to question 3 really define how to make the service REST.

We'll cover the first two in this post, and the third in a subsequent post.

Tuesday, September 30, 2014

Many of us have, at some point or the other, created and consumed web services. Many of us have created and consumed RESTful (or REST) web services, because that is the trend nowadays. Or have we actually created a HTTP based web service and not really a REST web service? It's pretty easy to create a HTTP based web service with, for example, Microsoft's ASP.NET Web API 2 framework and provide the consumer of the service with a JSON payload. But there is more to a REST web service than 'just returning a JSON payload'. So what is a REST web service? Read the full article here. Part 2Part 3Part 4

Saturday, May 3, 2014

Even a cursory study of the history of the internet, especially after the advent of the World Wide Web, indicates the power of the medium. In terms of users, it has grown 588.4% between Dec 2000 and June 2013, from around 369 million to 2.4 billion, though only 34.3% of the world's population had access to the internet in this period [source]. The penetration is expected to grow to 45% by 2016, bringing the digital world to almost 3.4 billion users.

Businesses and governments have taken advantage of the internet, especially of the WWW, to create applications that many of us can't do without. Shopping for most of your needs, reservation of your airline, train, bus tickets, planning and managing your holiday tours, most banking activities, paying your bills, buying and renewing your insurance, filing your tax returns - all of these can be done over the internet. Streaming music and video keeps us entertained, social networking applications and blogs fulfil our need to share, Skype and WhatsApp help us to connect. Google Drive, Onedrive, Dropbox store our important documents and allow us to share restrictively. Almost every sphere of activity have applications dedicated to it, photography, ornithology, skill enhancement, stocks, funding of ideas to production, you name it, all allowing us to generate and use content.

All of these generate data, huge volumes of it. The infographic in this article gives an indication of how much user driven data is generated every minute. CISCO estimates total Global IP traffic by 2017 will be 120643 PB per month up from 43570 PB per month in 2012.(What is a Petabyte (PB)? also see here).

Not all data is user generated.

A example is India's 'Adhar' initiative, implemented by the Unique Identification Authority of India [UIDAI]. Briefly it aims to provide a 12 digit unique identification number to every Indian (that's over a billion people) starting August 2009. It's mandate is to provide these numbers to 600 million (60 crores) citizens by 2014. It enrolls a citizen by collecting his/her iris and thumb scans and demographic data. Each enrollment pack is 5 MB of data. Till now it has generated 1500 PB of data [source].

Every department of governments generate a humungous amount of data. Analysis of these data create more data, usually in the form of reports. Government rules and regulations mandate business to generate and publish to the public domain their Annual Reports. Organisations like Lexis Nexis collate business data from the public domain all over the world and create tools such as their Dossier Suite.

Look around you and everyone is creating data and very large volumes of it: the United Nations, stock exchanges and financial and credit rating organisations, researchers and scientists, even machines and processes where sensors report the working parameters at regular intervals.

The question then is: How do we persist and maintain large volumes of data? And how do we use these? We’ll check these out in subsequent posts.

About Me

My name is Santanu Sen. I am primarily involved in the creation of software. You can view my profile on Linkedin here.

The intent of this blog is to keep and share notes on my experience in the creation of software. Though I use Microsoft tools, it is becoming increasingly clear that these are not always sufficient to create the solution the world requires today. One then requires to understand and integrate other technology and tools to create acceptable solutions. These are the areas I will post on.

I also express opinions. Opinions expressed in this blog - unless I am quoting someone - are mine and do not represent anyone else's view in any way.