Friday, 24 April 2009

Spring Innovation

So, Easter (with its attendant excuse for a nice vacation) has come and gone, the sun is shining here at HQ in Welwyn Garden City, and we're all getting exciting about launching an innovative new and improved Tesco Wine site in the coming days.

Innovation is a word that is thrown around a lot these days. For me, in the context of our wine and grocery service, its meaning is simple: Making it easy, convenient, price competitive (and fun) for customers to shop groceries and wine with us such that we earn their lifetime loyalty.

Shopping for groceries is the strangest form of e-commerce that the internet offers. Take a look at the reasons you and I shop in general on the web:
  1. Aspirational - a product or service I am looking forward to owning, using or experiencing.
  2. Infrequent, occasional purchasing - aspirational products are 'wants' not 'needs'.
  3. A single item, or at least a low quantity of that item. So, a book; a DVD; a software application (or that thing you now regret bidding for on eBay).
Contrast this to grocery shopping online:
  1. Non-Aspirational products (well can you get excited about buying baked beans?!)
  2. Frequent, regular purchasing (usually once a fortnight for me).
  3. Large quantities - I often put upwards of 5o items in my basket.
So lets see - compared to the excitement of buying a great book or enjoying the latest music when I can afford it, grocery shopping is where I have to buy loads of stuff - regularly and frequently - and not be excited about much of it...

Perhaps you now glimpse the challenge, and why the business makes sure I concentrate a lot of R&D effort on our grocery operation, whether up front for the customer or behind the scenes with our picking and delivery staff. It's why I label the word 'innovation' as: Easy, Convenient, Price-Competitve, Fun, Earning Lifetime Loyalty.

We don't make it easy on ourselves, do we, given my description of the nature of grocery home shopping? But getting this right is so important that everyone in the Tesco HQ building is working to deliver the new wine application shortly and the new grocery application over the coming months.

And since we know what it will do for the customer experience, none of us can wait to launch them!

Thursday, 2 April 2009 API to become more RESTful

I've been won over in the face of some feedback from Tesco API developers: The Grocery API will retain its SOAP interface for communication with client applications but it's also going to get a REST interface too,very soon.

The Tesco API web service endpoint uses SOAP ('Simple Object AccessProtocol') which allows the full service description to be shown to clients in a long and complex XML document. This is no problem if you have Microsoft Visual Studio 2008 since a rather nice 'wizard' takes care of reading this XML configuration and creating lots of client-side code so that your .Net client application can use the web service easily.

However many other Integrated Development Environments do not have this Microsoft-borne luxury, not to mention that fact that some developers like to hand-craft their code directly. To these IDEs and developers, SOAP is a tall cliff to climb to get to configure our service with their client applications. Time and time again I get emails saying "Why can't you implement RESTful services for your API?".

So here I am this morning poring through the book "RESTful .NET" by Jon Flanders (O'Reilly publishing) and I suddenly understand why REST ("REpresentational State Transfer") is so popular: Whereas SOAP performs many actions from one web address (using complex XML documents to describe and access each action), REST's implementation of those same actions uses one-web-address-per-action. REST adopts the true name of a web address - a Uniform Resource Identifier - to describe each action.

Let me show you:

So, our SOAP service endpoint is all at:
...and interacting with all the methods and objects there takes sending and receiving XML documents to/from that service endpoint. Inspecting the web address above gives you no clue as to how to, for example, search for 'chocolate'.

Instead, REST simplifies this by accessing methods through the web address call itself. If I get the RESTful design right, searching for chocolate could be as simple as (contrived):

To get to my favourite organic cider using its barcode could be:
...and anyone can type that manually into a web browser and get the same results as easily as a client application, albeit just data.

What about logging a customer in to get the search from their store? Simple. Just log the customer in using (note the secure 'https'): get a result back containing a unique session ID, e.g. "f7236grrg2g2rg7fg642", and then:

Adding to a basket or updating the quantity? Just use the Product ID that is returned with any product search, plus a quantity (here I show a possible alternative, using a query string):

Delete from a basket (again using a query string but alternative syntax is available):

...and so forth (please remember these are contrived REST actions to show how much easier it is to understand).

Simple, straightforward, understandable - this is what REST offers and the more I read Jon Flanders book the more I have become a fan.

Once I have finished the book I'll go and do some design - but if you are already a seasoned REST developer and there is any direction you think I should go based on your experience I will be happy to listen - just email me at nick 'at' lansley dot com.