dnene

This article is somewhat misleading. Although the image caption says Nominal GDP, the bottom of the image says the GDP is in PPP terms.

AFAIK the most optimistic estimates make India the second largest economy in nominal terms measured by exchange rate no earlier than 2050.

India is expected to be growing pretty fast. But nowhere close to the rate which would be needed for this to be true in currency exchange rate terms. PPP terms really doesn't mean much.

You may want to take a look at Rietveld which is a clone of the widely used mondrian tool within google.

http://googlecode.blogspot.com/2008/05/guido-van-rossum-rele...

The NoSQL hype happened because people wanted to explore and promote alternatives. The NoSQL name happened since there was a need to provide a moniker to the alternatives. Since this was a hype and movement based on otherwise real need, it is likely to have happened even if the name was something completely different say FreeQL (or whatever other catchy name). The post isn't arguing there shouldn't be a name. All it is attempting to point out is that it should be a meaningful and appropriate name - else what you think (when you hear the name) and what you get (when you actually dig into the details) are very different. The current name actually makes it harder for newer participants to properly grok these storage systems - which wasn't perhaps the goal in the first place.

I think the blog post clearly mentions that there is indeed one standardised resource management service for REST over HTTP, and given its simplicity and ubiquity, that particular standardised service orientation is uninteresting and largely ignorable.

You introduce aspects orthogonal to the post argument which is why the post does not even attempt to address them and you seem to think the author doesn't grok them.

HTTP method + a Unique URI are the essence of the Uniform interface constraint of REST. They are very much a part of REST. How the real world uses them has no bearing on their validity. This has to be managed by better informing the real world not by questioning the very notion itself. Linking via hypermedia is an essence of the HATEOAS constraint of REST. Both are orthogonal yet complementary aspects of REST. A discussion can be had about one without necessarily talking about the other as this blog post does.

On the other hand transparency vs. opaqueness has nothing to do with REST API design per se. All REST recommends is that clients shouldn't design themselves to assume specific semantics into the URI substructure nor should the services guarantee them. However structured design URIs do not at all fall foul of REST from an API design perspective, and help both development and debugging substantially.

I suspect you've introduced both issues related to Client API usage and used them to question serverside API design. The issues are not incorrect but the level of abstraction at which you choose to address them is something I would differ with.

And I'm sure I nailed first three but have no clue about the fourth. tried characters and numbers. Not sure if numbers should be attempted forward or reverse.

I agree with that. Its just an (imperfect) proxy measure of the depth / extent of unit testing. Asking how much code coverage is likely to give a better reflection of the effort behind unit testing rather than just a - "have you done unit testing".