Representational State Transfer (REST) and URLs in InfoGrid
We might as well up-front about it. In our view, if there were a Nobel price for software technology, the one accomplishment that stands heads and shoulders above the rest (of at least the rest we know of) in the past 20 years or so in software-technological progress is the invention of the REST model. Many have pointed out how simple REST is, and how little it actually defines. That, in our view, is not a bug but a feature; an absolutely exceptional feature that requires true brilliance to accomplish. A consequently applied REST-ful architecture is one of the most simplifying, and consistency-enforcing architectural approaches that we are aware of.
It is also the only approach that allowed the internet to grow at the rate and to the size at which it has grown in past years. Can you imagine an internet growing at the same rate based on WS-whatever? That observation alone should give us pause.
On the other hand, it is clear that REST by itself is a great architectural principle and protocol, but of course far from sufficient to define a software architecture for InfoGrid or anything else. So we extended REST for the purposes we have for InfoGrid, all while hoping to not violate any of its core principles but add additional richness to it.
In no particular order:
- We define that behind each URL not only resides a file or two (what HTTP calls a Resource), as it is commonly assumed when discussing REST, but an object (in the object-oriented sense) that might have complex behaviors and state. On the network, the only thing we see of it is what we can observe by the use of the REST operations on it. We call this object a MeshObject.
- We notice that we often observe the same information on the web accessible through two or more separate URLs. This includes the deliberate exposure of the same (conceptual) MeshObject at different URLs, copying, cacheing, syndicating etc. Thus, we allow the same MeshObject to be exposed at different URLs, including through specific mechanism for managing Replicas along a ReplicaGraph using XPRISO.
- We notice that websites often expose the (semantically) same information at slightly differing URLs with different rendering, for example to serve different clients or audiences or client preferences. An example would be an RSS feed that contains the same information as an HTML page, each of which might further be parameterized (e.g. maximum number of items on page). We interpret this observation as clients accessing the same MeshObject, but conveying, as part of the access, preferences on the type of resource they wish to receive from the MeshObject. The MeshObject - actually, the Viewlet Framework in conjunction with the MeshObject - has a large amount of discretion on whether and how to honor those preferences.
- We observe that many hyperlinks on the web are not just tools of convenience, to say, not having to remember the URLs of certain resources, but represent semantic relationships. For example, a web page containing past-due accounts with hyperlinks to the details of each past-due customer represents the semantic relationship between the past-due amount and a customer. Hyperlinks are just the surface representation in how they are rendered for easy human consumption. Correspondingly, we designed a graph structure for MeshObjects. We then offer facilities how to render those relationships as part of the negotiation between client and MeshObject about how the returned resource should be rendered. If anything, this is probably the most conceptually substantial addition that InfoGrid brings to REST and the web.
- REST is silent on the subject of security and access control. We subscribe to the notion of REST-ful identity (the leading contender of which is OpenID) and allow MeshObjects, or mediators on their behalf, to exhibit different behavior based on the identity of the client. The InfoGrid philosophy does not care by which means a client authenticates; only that any MeshObject has the ability to determine whether a client authenticated, and as who (using a URL to - conceptually - identify the MeshObject that is the client), and based on that information, adjust its behavior.