Tuesday, August 01, 2006

Feeds vs Reads

James Governor talks about the difference between a portal-based approach to delivering content and an approach that provides APIs/Feeds.

It's an interesting question. How do I interact with online services?

A few years ago, there were tens of websites I would visit on a daily basis. Now there are probably only three or four (my share dealing account, GMail, IBM intranet homepage and that's about it). Everything else I used to read regularly (and much more) is now delivered to me in my RSS reader.

However, the question goes a little deeper.

Consider my small-time share trading dabbling - or my flat purchase that is currently grinding its way towards completion.

I'm a fairly obsessive person so I check my stock prices several times a day (I know, I know... I really shouldn't) and I check the online tracker at my solicitor's website a couple of times a day too. In both cases, it would be more efficient simply to be informed when something has happened.

But what happens when you start looking at more complicated things?

My share dealing website aggregates lots of different pieces of information: the shares I own, the purchase price, how many I own, the current price, the tax treatment, the dividend history. The design of the site is an attempt to optimise my access to all this information.

But what if I wanted to aggregate this information with my National Savings holdings, my current account balances and my IBM stock and options?

An API into each of the relevant providers would make this far easier but then we get onto the harder question of: what functionality should the API expose?

If it simply provides me with a dump of all the data then that puts a heavy burden on me. If it provides only "useful" subsets of data, then I have to hope the "useful" subset is the one I want.

As a piece James links to says: being able to join across different feeds is absolutely critical... and it's not something I've seen a good solution to yet in the Web world.

Joining across disparate data sources is something that WebSphere Information Integrator has been able to do for some time (e.g. perform a query that joins a table in SAP with a table in Oracle... if I've understood the sales pitch correctly!).... extending that to web services would be extraordinarily powerful.

No comments: