Some time ago I co-wrote an article with Raj regarding Representational State Transfer (REST) used in conjunction with Domino. The article Creating RESTful IBM Lotus Domino applications in a Web 2.0 world with Project Zero touches on the characteristics of REST applied to Domino data. Specifically, it creates a REST application layer in front of the Domino application server. While the article has a specific use case, it points out that one can quite easily abstract the use case implementation into one which facilitates a more generic approach to accessing Domino data using REST.
As I worked on the article, one specific design issue was constantly present. If you've used the Notes View portlet, a HTML form based mechanism attains the following (using roundtrip server POSTS).
- A list of servers in a Notes domain
- The databases on a selected server
- Lastly the list of views in a selected database
This information is ultimately used to construct a URL of the format http[s]://<server>/<database>/<view>?ReadViewEntries.
What seems like a rather straightforward feature belies varying technologies to accomplish the requirement. This time, I'll pair the previous steps with the underlying implementation.
- To obtain the list of servers, an LDAP search is conducted against the organization for a list of Domino servers. This looks something similar to (&(o=IBM)(objectClass=dominoServer)).
- To obtain the list of databases, a DIIOP function is used. The Notes Java class Database.getDirectory() is essentially the mechanism here.
- To obtain the list of views, an XML input stream (HTTP request) to the web server is made. This looks something like http[s]://<server>/<database>/$defaultoutline?readentries.
Inevitably when problems were reported with the picker feature, it began with a two or three minute explanation of the above steps. The varying implementation technology ultimately required varying administrative requirements. The picker feature explanation was usually followed by a "Well, I didn't know it did that" type response. Consequently, this is what I feel is great about REST. Because it is an underpinning in the Web with which we are all familiar, understanding and even exploiting REST simply makes sense. So rather than designing and then having to explain that the picker feature is a pipe of LDAP data to DIIOP data to an XML input stream, it is much more digestible to hear that the following requests are made to the server.
The end result is a foundation which I feel is well understood and dovetails well within rich internet applications.[Read More]