RESTful web service - versioning the API

This is the fourth post in this series of posts on RESTful web service.

Part 1, Part 2, Part 3

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.

This is the fundamental reason to version APIs.

Read the full post here.

RESTful web service - media types and resource representation

This is the third in this series of posts on RESTful web service.

Part 1, Part 2, Part 4

In this post we will examine the role of internet media types, especially the 'application' media type in a REST service.

The media type, to a large extent, describes the contract between the server and the client in a REST web service.

Read the full article here.

RESTful web service - how do I design one?

This is the second post of the series on RESTful Web Service.

Part 1, Part 3, Part 4

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.

Read the full article here.

RESTful web service - what is this?

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 2
Part 3
Part 4

The rise and rise of data

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.

IE's legacy browsers - will they ever go away?

“W3C publishes documents that define Web technologies. These documents follow a process designed to promote consensus, fairness, public accountability, and quality. At the end of this process, W3C publishes Recommendations, which are considered Web standards.” from Standards FAQ.

The recommendations are not binding, but as the W3C says: “W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.”

And would make us developer’s creating web applications more productive.

Microsoft, in spite of its large representation in the W3C Working Groups, has been a laggard at proactively adopting these recommendations in its browsers. It has thus gifted us a bunch of what it now calls its ‘legacy browsers’ - IE6, IE7 and IE8, which, whether we like it or not, has still to be supported if our web applications/sites are to reach a greater audience.

A case in point is the CSS Color Module Level 3, one of the modules of CSS3, which was endorsed as a W3C Recommendation on 7 June 2011. The first W3C Working Draft was published on 22 June 1999, it became a W3C Candidate Recommendation on 14 May 2003, back to a W3C Working Draft on 21 July 2008, and a W3C Proposed Recommendation on 28 October 2010.

Tantek Çelik [Microsoft’s representative till 2003] and Brad Pettit [Microsoft’s representative] have been associated with this recommendation right from the first working draft to its endorsement as a recommendation.

In this period, IE went from IE6.0 to IE9.0, Firefox to version 5.0 and Chrome to 12.0. The table below indicates how Firefox and Chrome were early adopters of CSS3, whereas Microsoft waited until IE9.

Table 1

How does Microsoft’s apathy affect us in development? Several ways:

1. IE is the most used web browser.

Figure 1: Web browser usage by country in September 2011 [Source: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers]

2. StatCounter estimates the usage share of web browser for September 2011 as below.

Figure 2 [Source of data: StatCounter]

3. The usage share of various versions of IE for September 2011 is shown below (source: StatCounter)

Figure 3 [Source of data: StatCounter]

Figure 3 means that the usage share of Microsoft’s legacy browsers is 32.72%. This is a large population and cannot be ignored.

So why do we have a such a large population using IE’s legacy browsers? 2 reasons in my opinion.

One: Microsoft bundles IE with its OS. So IE is kind of available out of the box. The fact remains that the majority of Internet users are not techies or geeks like you or me. The browser is just another tool to get their work done. And if it is available out of the box, they’ll use it. They don't care if the IE version they are using is W3C compliant or otherwise, as long as it can get their work done.

IE also has a tight integration with the OS. So while you will be able to install Firefox 7 on Window XP or Window 7, IE9 will work only on Window 7+ (though its legacy browsers can run of this OS). The high usage of IE8 is because it was released for Windows XP, Windows Server 2003, Windows Vista, and is the default browser for Windows 7 and Windows 2008 R2.

Window XP and Window 7 more or less share the honours as per StatCounter’s data of September 2011. This delays adoption of IE9 as the primary browser.

Figure 4 [Source of data: StatCounter]

Two: Figures 1, 2 and 3 indicate internet usage. My experience is that the usage of IE’s legacy browser is even greater in intranets in corporate, business and government - this follows from the fact that the browser is bundled with the OS. These have a large user base and the cost and time of upgrading the OS or the browser is huge.

So, IE’s legacy browsers aren’t going away soon. And we will continue to fret for a while longer about the pain these give us. And because we create applications for the masses, we need to write code to support both these and the modern browsers. Something like this ‘best practice CSS’, even though it will never validate.

.50PercentOpaque
{
    opacity: 0.5;     //W3C CSS Color Module Level 3 compliant browsers
    filter: alpha(opacity=50); //IE legacy browsers
}

Weird Architecture

Sometime back the technical consultant of a customer accused me of having created a ‘weird architecture’ for her project. And this after we had completed an iteration that met agreed goals, work which was commended by the customer as ‘brilliant’.

This was a Web 2.0 application, built on the ASP.NET framework, written in C# and targeted the .NET Framework 3.5, with a SQL Server 2005 database, and hosted on IIS 6.0.

So what was ‘weird’?

The project consisted of several web applications and was deployed on the IIS in the manner shown in Figure 1. A web site was created and web applications were deployed as virtual directories under this web site.

Figure 1

A separate Application Pool was created for this web site, as indicated in Figure 2.

Figure 2

From the above example, Application1 could be accessed from the URL http://www.myapplication.com/Application1 and so on.

In the past few years, I have come across several applications which have been or will be deployed in this manner. What was/is the motivation for deploying the applications in this manner?

We analyse this through a couple of case studies. Read the analysis here.

The software devlopment crisis

Some blunt observations on the state of software development practices today, and a way out.

See other Tech-Ed 2011 videos here. Of particular interest to me were those tagged as Development Practices and Architecture.

The privilege and responsibility of software development

From Grady Booch:
".. It is a privilege because -- in spite of some inevitable dark days -- we collectively are given the opportunity to create things that matter: to individuals, to teams, to organizations, to countries, to our civilization. We have the honor of delivering the stuff of pure intellectual effort that can heal, serve, entertain, connect, and liberate, freeing the human spirit to pursue those activities that are purely and uniquely human. At the same time, we have a deep responsibility. Because individuals and organizations depend on the artifacts we create, we have an obligation to deliver systems of quality in a manner that applies scarce human and computing resources intentionally and wisely. This is why we hurt when our projects fail, not only because each failure represents our inability to deliver real value, but also because life is too short to spend precious time on constructing bad software that no one wants, needs, or will ever use. As professionals, we also have a moral responsibility: Do we choose to labor on a system that we know will fail or that may steal from a person their time, their liberty, or their life? These are questions that do not have a technical answer, but rather are ones that must be consciously weighed by our individual belief system as we deploy technology to the world. .." The privilege and responsibility of software development

And from the Software Engineering Code of Ethics and Professional Practice:
".. Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems. Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. .."