Widgets and web services

Behind (most) widgets you’ll find one or more data sources – whether a relational database, a bunch of linked data or even a text file. The widget is basically an interface to this data. The relationships between widgets and their data sources fall into two main types:

• Retrieval: the widget asks the data source a question and uses the answer for some purpose (usually display)
  
• Alteration: the widget causes a change to be made in the data source

So, in our Library widget, an example of retrieval would be to show a list of the items a user has on loan (no change to underlying data). And an example of alteration would be renewing one of these items (change made in underlying data).

Which means that widgets need a way of talking to their data sources.

Most widgets talk to their data sources through web services (also known as APIs) - little scripts which sit on your web server and mediate between your widget and your data.

They work something like this - your widget makes a request to a web service - either that some data be retrieved, or that a change be made in the data. The web service translates the request into data-speak and sends it on to the data source. The data source processes the request, makes any alterations, and sends back a response. The web service translates the response into widget-speak and sends it back to the widget.

So, why can’t widgets talk to their data sources directly? Why the need for the middle-man? There are four main reasons:

• Security – if your widget is talking to the data source directly, it is likely to contain passwords. Because widgets are usually written in html/javascript, pretty much anyone can access the source code and so access your passwords.
• Efficiency – web services are reusable. Say you have three widgets that need the same bit of data. You can write one web service to make the request and do any processing on the response, and all three widgets can use it.
• Ease of use – most widgets are written in html and javascript. Basically, it’s pretty easy to make calls to web services from javascript. Making calls to data sources directly from widgets is a bit of a nightmare.
• Innovation – if you have a bunch of web services sitting on your server, you can choose to publish them. This means that other developers can build systems and functionality around your data. Which is not only pretty exciting, but also saves you having to do everything yourself.

Many systems now come with their own set of proprietary web services for talking to their data source. These should be written up in your system’s documentation. If the system has no web services or it doesn’t have a web service for what you want to do, it’s pretty simple to write your own.

EXCEPT - reflecting the two types of request you can make to your data source, there are two types of web service - those that retrieve data and those that make alterations to your data. Most systems will allow you to write your own web services to retrieve data BUT most systems will insist that you use their own proprietary web services to alter data in the system.

So, going back to our original example, we have a locally written web service which retrieves a list of a user’s loans, but we use a proprietary system web service to renew one of those loans.

Our widgets use a mixture of locally-written and proprietary web services to relate to data sources, and (unless your system’s proprietary web services are truly excellent) you’ll probably find yourself doing the same. I’ll stop here before this post turns into an essay, but in future posts I’ll outline how to write web services, and how to use them.