RESTian web services (for modelling)

I'm doing some long overdue rapid learning about the basics of REST (REpresentational State Transfer), the architecture of the web, and Service Oriented Architecture (SOA). Some articles by Paul Prescod on REST, and a more recent one by Hao He on SOA are the material.

The basic ideas, I think:

URIs identify everything, can even encode the stage of a process. Paul Prescod:

In particular, the web's central concept is a single unifying namespace of URIs. URIs allow the dense web of links that make the Web worth using. They bind the Web into a single mega-application.

URIs identify resources. Resources are conceptual objects. Representations of them are delivered across the web in HTTP messages. These ideas are so simple and yet they are profoundly powerful and demonstrably successful. URIs are extremely loosely coupled. You can even pass a URI from one "system" to another using a piece of paper and OCR. URIs are late bound. They do not declare what can or should be done with the information they reference. It is because they are so radically "loose" and "late" that they scale to the level of the Web.

A simple, universal, API; with a small number of verbs, each of which can be applied to; agreed encodings of data.

[The HTTP protocol; GET, PUT, POST, DELETE; XML encoded data.]

Paul Prescod:

Of course you may actually implement it on the server side however you want. But the API you communicate to your clients should be in terms of HTTP manipulations on XML documents addressed by URIs, not in terms of method calls with parameters.

Some interesting ideas surface. An in-the-pipeline (not really in the pipeline yet, if I'm honest) paper regards the difficulties of defining useful software interfaces for hydrological and hydraulic models -- in all their colourful variety -- which allow models to be switched as needed. I have argued that we need to step back, and define a standard way of defining those interfaces, and allow interface discovery to deal with the rest. This feels very similar to the notion of using a general protocal such as HTTP to move data around, constraining the form of that data only at a higher level.

Paul Prescod:

Hopefully I have demonstrated that REST can address all of the industry buzzwords successfully. Now let me ask for your help in promoting addressing to the same level. We as an industry need to understand that this is not just an issue, it is the issue. Until we get it right, we cannot expect to make progress on other issues. As I have shown, it is the basis of security, web service orchestration, and combination. It is the difference between a unified web services Web and a balkanized one.

For instance, a balkanized way to reference about a particular stock value is as WebService.stockQuote("KREM"). This syntax is particular to some programming language and is not available outside of it. It can only be used by some other service through some form of glue. A universally addressable way is "http://www..../webservice/stockquotes?KREM". This can be accessed by any application anywhere in the world (with proper security credentials) whether or not it was written to understand stock quotes.

This is interesting too. As a side effect of describing models using RDF, I am being forced to think about how one might refer to models, parts of models, inputs and outputs of model, using URIs. Which bits are public? Which are only needed in a local context and can be left as RDF blank nodes? Which bits need explicit URIs, but not URIs which indicate a retrievable resource?

In What is Service-Oriented Architecture>, Hao He presents some valuable concepts, too.

A real dependency is a state of affairs in which one system depends on the functionality provided by another.

…

If you travel overseas on business, you know that you must bring power adapters along with you or your life will be miserable. The real dependency is that you need power; the artificial dependency is that your plug must fit into the local outlet.

I think this is, or is part of, what I referred to as "intrinsic" and "extrinsic" complexity in my thesis.

"Artificial dependencies should be reduced to the minimum but real dependencies should not be altered."

SOA achieves loose coupling using two architectural constraints:

1. A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
2. Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.

With web services, the simple and ubiquitous interface is the HTTP protocol with its four verbs. The extensible schema is achieved using XML vocabularies.

There is no reason this extensible schema could not be RDF/XML, with snippets of RDF graphs being passed around. Care should be taken, perhaps, to avoid using RDF when plain XML would do (with mapping at the client or server end as desired).

I'm getting quite excited about the potential for a RESTian web service holding model definitions, which can be annotated, assembled, and so on using client tools, and the results pushed back to the server. When a new model is developed, the papers describing it can provide a URI, from where the reader can obtain a formal description of the model, which they can use to validate the claims made in the paper. We might even move a little closer to how science is supposed to operate (repeatability got lost in the rush to publish somewhere along the line).