RESTful web services and information sharing

For years web services have been identified with SOAP and XML-RPC and creating and using web services has been considered a task for advanced programmers, a situation that has limited the large-scale adoption of this technology.

Over the last few years, many big actors (1) in the Internet have started offering remote APIs through RESTful (2) web services.

Using RESTful web services is very easy: each function in the API has a URL and may accept a number of parameters. An HTTP request to that URL will return a response in an agreed format, usually HTML or XML. Using XML of course allows for more advanced processing of the response, while using HTML allows easy (but less customizable) embedding of the response in a web page. When using XML, adopting widely used metadata sets like RSS, Dublin Core etc. makes parsing very easy and allows for code re-use and easy integration of responses from different web services.

The very little information needed to access RESTful web services (the URL, in some cases the accepted parameters and the format of the response, which can also be inferred from he response itself) makes this technology very “loosely coupled”. Loose coupling and “hackability” go together: they have been identified as two key approaches that distinguish Web 2.0 from Web 1.0 (3) and they have both proved very successful in attracting users to services.

In communities where information sharing is at the beginning and / or there are limited resources and capacities, the use of RSTful web services, combined with the adoption of common metadata sets, is the easiest, most efficient and cost-effective way to implement collaborative information services.

The simplest and best know RESTful web service are RSS feeds: they are accessible at a URL, sometimes optional parameters allow to dynamically create the response, and they return an XML response with a standard metadata set.

Another effective way of leveraging REST for information sharing is building distributed architectures based on harvesting following the model of the Open Archive Initiative.

A couple of examples of information services based on REST in the agricultural community:

- AgriFeeds
This is an agricultural news and events aggregator. It aggregates news items from several feeds and allows for the creation of aggregated custom feeds that can be called at special URLs with special parameters for customization.
The metadata sets used are RSS for news and RSS extended with a special Application Profile

- The ARD Web Ring Database of organizations on EGFAR
This relies on HTTP calls to special URLs accepting one or more parameters and returning an XML or HTML response.
The system does not rely on a common metadata set for the moment, but a common Application Profile will be adopted very soon. Also, additional parameters for improved search options will be added.

---

Notes:(1) Google and Amazon. for example. Just to give an idea of the shift in approach to web services, recently the famous php PEAR technology for plugging in modules has discontinued the SOAP web services and software updates are only available through RESTful web services.

(2) REST means Representational State Transfer and RESTful technologies are those that rely on stateless transactions, like for instance stateless HTTP requests. Quite often, REST is tout-court identified with stateless HTTP requests.

(3) See Tim O’Reilly, “What is Web 2.0“