Tesco API now running in Microsoft Azure 'cloud'.

Well I'm delighted to say that the Tesco API is now running in Microsoft's Azure cloud computing service and it seems to be working just fine. This means that I can scale the service beyond my single server on which the API was hosted until now.

I have also made a change to a few of the methods available from the service so I have placed below a message sent to all API developers over this weekend. My boss also saw the message and declared that the way I have authored it as 'a roller coaster ride', since I am write it as 'good-point then bad-point then good-point', and so on.! Oh well, this ride is fun, but you must hold on....

Dear Tesco API Developer

This message is to tell you of a 'breaking change' being made to the Tesco API this weekend, and to let you know that the API is now being hosted in the new Microsoft Azure cloud computing service.

---

First of all, the 'breaking change' (where your app will have an error if it tries to use the API):

There are three methods that enable your application to receive product lists, namely:

ListProductOffers()
ListProductsByCategory(), and
ProductSearch()

These now have an additional parameter added to the end of the list of parameters:
bool getRatings

You will need to update the API service end-point reference in order for your Integrated Development Environment to 'see' the new parameter and allow you to code it. In Visual Studio 2008, right-click the TescoAPI service reference you have set-up (visible in Solution Explorer window) and select 'Update Service Reference'.

You will need to supply a boolean 'true' or 'false' to this parameter, which will tell the API whether to get product ratings for each returned product, or just return the product objects without setting their Rating properties.

Setting the getRatings parameter to 'true' will continue to recreate the behaviour of these methods as before.

However, setting the parameter to 'false' will dramatically increase the speed at which the API returns the products - I have seen more than 400% decrease in wait time! The Rating property of returned product objects will always be zero if the parameter is false, regardless of the actual rating.

This change comes about as a result of feedback from several developers saying that the product search could be slow, with 'nothing to show the customer' for some seconds after launching their application. A good work-flow after this change will be to use the product searching methods with getRatings set to 'false', then populate individual product ratings on a separate thread by calling the search with getRatings set to 'true'. That way the customer gets to see products quickly, and ratings can be shown after a few more seconds, notwithstanding the feeling that it's a bit daft calling the same thing twice. Correct but community technical previews are all about identifying silly things, mais non?!

Even better, it may be that, as the customer focuses in on a smaller set of products, you call the GetProductRating() method on each product of that smaller set.

Or I go and think of a much better way! But for now at least the above ways will keep your app. going.

Ratings are a subjective feature at the moment and I will be interested in hearing what you think of them. I'm certainly not going to let them slow down core functionality.

---

Secondly, the Tesco API is now running in Azure, the Microsoft cloud computing service. This means I can offer a far more scalable API than on my single server solution.

However, Azure is still pre-beta and there is a complication: When you re-configure your Tesco API service end-point to point to the Azure URL, you are likely to get an error! This is because Azure is exposing internal machine names rather than external web addresses, which will upset Visual Studio 2008's "Configure service reference" wizard.

Fortunately, the workaround is simple. Just before you wish to change the end-point to point to Azure:
1) Configure/Update your service endpoint pointing to lansley.com to ensure it has the latest configuration (including the 'breaking change' above).
2) Open up your text find/replace facility in your IDE (in Visual Studio 2008 just press CTRL-H).
3) In the 'find' box enter the lansley.com end-point: http://www.lansley.com/TescoAPI/TescoAPI.svc
4) In the 'replace' box enter the Azure end-point: http://tesco.cloudapp.net/TescoAPI.svc
5) Ensure you have the 'replace all' scope set to 'everything in this project'.
6) Hit 'Replace All' (in VS 2008 client apps, I have found the 'replace' occurs more than 40 times).
7) Compile and test.

Unfortunately whenever I announce a new function or a 'breaking change' you will have to switch the service end-point back to lansley.com and then 'find and replace' back to Azure again. Microsoft are sorting out a fix and one day the problem will go away.

To overcome this pain, once I am happy the service is working without error on Azure, I will be releasing some of the constraints on the number of time you can use the API per day - and the product search limitations will removed completely. Give me a week to test all is well, first.

---

I have updated the documentation at http://www.lansleytech.com/tescoapiweb/reference.htm to reflect all this information.

Keep the feedback coming - we're sorting out a production team to carry the API forward into beta but we have no timescales on that just yet.

In the meantime, using the API on Azure means I can finish coding and testing a great new 'accelerator' for Internet Explorer 8 that will allow people to highlight food names on any web site and search for them at Tesco.com. They won't know but you will know the accelerator is using the Tesco API to work. You see? Code an API once and find a million uses!