Over the past few weeks we've started a "production line" of widgets where widgets start off life as ideas, become prototypes, then emerge as demos and gradually develop into more finished products. Watch this space for more news about some of the other widgets we have in "incubation" in the production line.
The first new widget to emerge from this production line as a "beta" release is a Reference List widget - this displays a list of journal citations and allows the user to filter them by various criteria like keyword and author. This could be used as a handy way for a course lecturer to disseminate the References relevant to various lectures within a course. It is powered by public JSON feed from a Google Spreadsheet which makes it easy for non-developers to maintain the source data. I'll blog a bit more about how this widget works in a later post.
In the meantime, I've set up a quick and dirty Gallery Page to show off our widgets as they emerge from the production line - you can see the Reference List widget in action on there, along with the two other widgets that are in a ready-to-demo state (see earlier posts for more about them). The widgets and the Gallery Page itself have some rough-edges which we'll tidy-up in the coming weeks but for now you get a flavour of what we've been up to. We also hope to supplement this demo page with a more "directory-like" page, a bit like an "app store", which will tell you more about each widget, and allow you to add the widgets to your own portals (e.g. Facebook, iGoogle).
Showing posts with label json. Show all posts
Showing posts with label json. Show all posts
Thursday, 15 July 2010
Tuesday, 8 June 2010
Proprietary web services and proxies
A couple of weeks ago I blogged about writing local web services to extract information and embed functionality. However, many data sources come with their own range of ready-made proprietary web services. The big advantage of using proprietary web services is that you don't have to write your own. The disadvantage is that (usually) you can't alter them. Unless you have a very good relationship with your system supplier, you're stuck with what you're given.
Most data sources will allow you to write web services which extract data from the system, but the majority won't allow you to write web services which alter data in the system. If you want to use functionality in your widgets rather than simply displaying information (i.e. renew books, rather than just say what you have on loan) then you may find yourself having to use proprietary web services.
Basically, if the existing proprietary web services do exactly what you want, use them. If not, you might want to consider writing your own to extract data. But as far as altering data in the system goes, you may well be stuck with the proprietary ones.
[In practice, we find ourselves using a mixture of local and proprietary web services for data retrieval, and proprietary web services for data alteration]
Somewhere in your system's documentation you should find a list of existing web services and some notes on how to use them. This should include the service address, input parameters and return values. Which translates as how to find the service, how to ask it to do something, and how it will respond. Pretty much the same as using locally written web services.
But there is one potential complication with proprietary web services. If you make a request to a web service from a browser and then try to read the response, the browser will first establish what the response is and where it comes from. If the response is in XML and the domain of the web service is different from the domain of the page calling it, the browser gets worried about security and the whole enterprise collapses.
There are two ways round this. If the proprietary web service has the capability to return its response in json then you don't have worry about where it's coming from. If not, you will have to write a proxy.
A proxy is an intermediate web service which can sit alongside your local web services, in your own domain. You access it just like any local web service, and your browser will treat the xml it returns as if it had come from a local web service.
When you send a request to a proxy it passes it on to the proprietary web service, reads the response and then passes it back to you. Because the proxy is not a browser it doesn't care where the proprietary web service is, and because the proxy is in your domain, your browser is cool with it too.
An additional advantage of going through a proxy is that if your system's proprietary web services return responses which are over-long, oddly structured or confusing, then you can talior that response on the way back so it gives you what you actually need.
We use one proxy web service to connect to all of our library management system's proprietary web services. So we pass the service name, and the request to the proxy. The proxy calls the appropriate service with the request. Then it processes it and returns it to the browser.
Most data sources will allow you to write web services which extract data from the system, but the majority won't allow you to write web services which alter data in the system. If you want to use functionality in your widgets rather than simply displaying information (i.e. renew books, rather than just say what you have on loan) then you may find yourself having to use proprietary web services.
Basically, if the existing proprietary web services do exactly what you want, use them. If not, you might want to consider writing your own to extract data. But as far as altering data in the system goes, you may well be stuck with the proprietary ones.
[In practice, we find ourselves using a mixture of local and proprietary web services for data retrieval, and proprietary web services for data alteration]
Somewhere in your system's documentation you should find a list of existing web services and some notes on how to use them. This should include the service address, input parameters and return values. Which translates as how to find the service, how to ask it to do something, and how it will respond. Pretty much the same as using locally written web services.
But there is one potential complication with proprietary web services. If you make a request to a web service from a browser and then try to read the response, the browser will first establish what the response is and where it comes from. If the response is in XML and the domain of the web service is different from the domain of the page calling it, the browser gets worried about security and the whole enterprise collapses.
There are two ways round this. If the proprietary web service has the capability to return its response in json then you don't have worry about where it's coming from. If not, you will have to write a proxy.
A proxy is an intermediate web service which can sit alongside your local web services, in your own domain. You access it just like any local web service, and your browser will treat the xml it returns as if it had come from a local web service.
When you send a request to a proxy it passes it on to the proprietary web service, reads the response and then passes it back to you. Because the proxy is not a browser it doesn't care where the proprietary web service is, and because the proxy is in your domain, your browser is cool with it too.
An additional advantage of going through a proxy is that if your system's proprietary web services return responses which are over-long, oddly structured or confusing, then you can talior that response on the way back so it gives you what you actually need.
We use one proxy web service to connect to all of our library management system's proprietary web services. So we pass the service name, and the request to the proxy. The proxy calls the appropriate service with the request. Then it processes it and returns it to the browser.
Subscribe to:
Posts (Atom)