Weekly Random links of Interest – ITaaS, Weiner’s downfall, LulzSec and BitCoins

Here are the random links of interest for this week. Have a good weekend.

IT as a Service – A stateless infrastructure architecture model.

Another great post by Lori MacVittie. Cloud is all about shifting to “service” mindset. “Service” is also the foundational concept behind SOA. Every cloud service model (IaaS, PaaS, SaaS) abstracts and decouples certain aspects from the layers below, resulting in a flexibility never seen before. Take the case of IaaS. By abstracting and virtualizing compute, storage and network, we are decoupling applications from underneath physical resources. This ultimately results in the unprecedented flexibility to move applications/workloads (VMWare’s vMotion, Cisco’s OTV etc) across machines in data center and across data centers – for load balancing, availability etc. However, this shouldn’t affect how the services (applications) are consumed. SOA’s way of achieving this is via WSDLs and service registries. At the code level, programmers would immediately recall  Martin Fowler’s Dependency Injection and Inversion of Control principles achieving similar objectives.

By looking at applications as “services” and adopting SOA principles, ITaaS can achieve benefits beyond IaaS.

Twitter & Anthony Weiner’s downfall

Must read. This articles ends with the following quote 🙂

“The details of web product design had led to the pants being pulled down on a promising political career.”

To me, the interesting part of the story is not how a promising politician’s career was put to an abrupt ending but the key product decisions that twitter team made early in the process and how those decisions changed lives of everyone in the last few years.

While twitter has more issues (here are some I face in my daily use of twitter) to solve, clearly the ability to follow someone without requiring his explicit permission has been the winner from the day one.

via @timoreilly

We screw each other over for a jolt of satisfaction

That’s a cheesy title, but one should read it. I have been following the @LulzSec twitter stream for the last one week as they are hacking sites (Sony, CIA, etc) and posting plain text user ids and passwords extracted from site’s internal databases for everyone to see.  In the beginning, I thought hacking sites that ignore basic security mechanisms (SQL Injection, Stronger passwords, Not storing plain text passwords of users in the DB etc) would send a messages to companies and IT organizations across to re-look at their web applications.  And to some extent, @LulzSec may have achieved this purpose. In the recent past, we have not seen such consistent and systematic hacking of sites and it got everyone’s attention about the continued ignorance of basic security practices in web applications.

But the subsequent act of @LulzSec posting the extracted usernames and passwords on public sites for everyone to see and download is a disastrous step. You cannot blame and punish naive internet users for having simple and same passwords across several sites when the so called “expert” application and system developers are not doing a good job in applying basic security practices to begin with. Look at what is happening now: These publicly available usernames and passwords are tempting many normal folks to try and access the same username and passwords on several other sites (facebook, paypal, gmail etc) and see if it just works.

Here is another who user went one step ahead and created a script to automate this process and posted the script itself on the github for everyone to use and try. Too bad.

Given that @LulzSec is so active on twitter, how long is it before they get caught ?

BitCoin, The New Money

If you haven’t heard of BitCoin, here is your hance to mint your own money, virtual money for free 🙂 Read more about here, here,  wikipedia link and of course yours truly quora link, answers for all your questions.

I came across BitCoin on the hackernews.com. After that so many people are posting links to news about bitcoin, one impatient guy couldn’t bear it any longer and wrote a safari extension to hide all bitcoin news on hackernews.com 🙂



Random Links – Week of 6th June 2011

Here are some random links that grabbed my attention during the last week:

  • 411 services. Builder Twitter apps without ever coding to twitter API.  You get to reserve a keyword and when someone replies with that keyword, you have a choice to return a static content or dynamically generated content via webhook (CGI script).  Nice.
  • Evaluating Text Extraction Algorithms. If you have ever done a project involving extraction of text from HTML documents, you would find this interesting. While you are at it, you may also want to look at author’s earlier posts. Lots of information out here.  Several years back, when I spent some time on this problem trying to detect the layout of the page and remove the clutter, I find none in the state of the art. Glad to see so many solutions out there now.
  • RightScale launches Hybrid cloud solution. Looks like the trains for hybrid clouds started arriving. With the argument about private clouds resolved and that they are here to stay,  hybrid clouds enablers are just what could make some of these enterprises look at public cloud.

Understanding the Good in “The Good, the Bad and the Ugly of REST APIs”

With several dozens of APIs getting published every month or so, it is kind of become a routine for a seemingly innocent “How to do REST” or “Guidelines for REST APIs” kind of blog posts become source of controversies around applying REST principles properly.

Last week, it was the turn of George Reese’s blog post titled “The Good, the bad, and the ugly of REST APIs” for the controversy.  There were several reactions and reactions to reactions on all aspects of his post.  Following tweet from George indicates the mood:

One of the things George’s blog advocates under “Good” list is:

Supporting both JSON and XML

I know you love {JSON,XML} and you think everyone should be using {JSON,XML} and that the people who use {XML,JSON} are simply stupid. But you’re not building an API for yourself, you are building it for everyone, including those who think {XML,JSON} rocks and {JSON,XML} sucks. I don’t want to get in the technical merits of either language or even the possibility that there might be distinct use cases for JSON vs. XML. The bottom line is that there are people out there who want to consume APIs in both languages and it’s just not hard or complex to support both.

To which William Vampenepe reacts in his blog post:

I disagree: Two versions of a protocol is one too many (the post behind this link doesn’t specifically discuss the JSON/XML dichotomy but its logic applies to that situation, as Tim Bray pointed out in a comment).

Now that confuses me. Supporting JSON and XML in my mind is no different from a resource supporting multiple media types and serve an appropriate media type using content negotiation.  The post he links to talks about SOAP and REST as multiple protocols. I don’t see the connection.

The other item on George’s “Good” list is:

Providing solid API documentation reduces my need for your help

Solid API documentation enables an individual to both understand the simple examples that help them get started as well as the complex ways in which they can leverage the API to accomplish advanced tasks

That doesn’t seem like a statement to be argued with, isn’t it ?  Apparently not so. Jan Algermissen posted a comment saying:

If you document an API, you API immediately ceases to have anything to do with REST. The contract in RESTful systems is the media types, *not* the API documentation.

I suggest you move that section to “The Bad”

This comment was met with ridicule by many folks including George and William terming it as nothing but silly.

My takeaway from that comment was that the documentation should focus on media types as the rest of the behvaiour of dealing with media types is fairly standard with REST.

Clearly, Jan Algermissen is no newbie to REST. But I am still baffled by the first part of his statement.  How can a little documentation with examples of request and response payloads (even at the risk of duplicating something very obvious in REST way of doing) make it so against REST.

Stu responds with his blog post defending Jan Algermissen’s comment and many other things.

Jan Algermissen’s comment about how when you’ve documented an API, you’re not really doing REST, is actually spot on, fundamentally, but is met with ridicule. I can completely understand how vacuous the comment sounds if you just want to ship an API nownownow, are being short-term practically minded, or are just playing buzzword bingo with architectural styles. But if we actually want to leverage the benefits of the style, we’d work on the core issue of having a generic media type or two for these sorts of use cases.

I am still trying to digest parts of Stu’s post. Most developers learn the best practices by looking at what experts in that domain recommend or see mimic real-world APIs from popular web sites (twitter.com, facebook.com etc). Unfortunately, of late, these are the wrong sources to learn the best practices from (Remember the hashbang controversy).

Here is something even more basic. Try and get a bookmark-able link to a specific tweet on twitter.com site.


(Updated 14th June 2011)

I would like to add one more the list of  “good”  of REST APIs.  I am sure all REST purists would now cringe at this. Try and publish WADL for your API. Goal is not to be able to do all weird stuff that tools force you to do with WSDL while consuming the service.  But it definitely helps your API consumers to leverage some tools that would further help them to understand the API better.  For example, check out this cool API console tool from apigee. Apigee API console takes a WADL and provides a nice way to navigate the API, exercise the API (including OAuth), look at the request/responses  and learn iteratively – all with zero coding and based completely on WADL.

It already supports several public REST APIs as an example.