The opportunistic developer is allergic to soap
For some time now I’ve been thinking about what I think of as the ascendency of the opportunistic developer in web application development. The phrase has unfortunate connotations for those who remember the ‘personas’ meme from some years ago when it was revealed that Microsoft had characterised three type of developer for three of its software development products. [1] and [2]. This post is not directly related to these archetypes (the opportunistic developer was called ‘Mort’ in the meme, a name which has become derogatory). Rather, I’m talking abut the developer who, regardless of their ability or their occupation wants to make quick use of something when they discover it, typically on the web.
The opportunistic developer prefers to use someone else’s service/component in the majority of cases. They will create their own software when necessary, and will choose to do so under certain circumstances, but they will accommodate a certain amount of compromise if it means they can get away with using something off-the-shelf. The opportunistic developer is still a developer, as opposed to a power user: they will still write code, just as little as they can get away with.
The proliferation of freely available web-services with simple APIs has created a happy-hunting-ground for the opportunistic developer - a few years ago they were inhibited by a lack of choice of available services to use. In addition to the usual concerns - stability, provenance, price… ease of use is becoming a more important differentiator.
In the JISC Information Environment, the norm has been to develop SOAP interfaces to services, almost by default. There are, no doubt, reasons why this has made sense in the past. However, if there is one thing which became abundantly clear at last week’s IE Demonstrator/CRIG event, it is that institutional repository developers do not want to have to use SOAP interfaces. Aside from the hard-core which is interested in pushing REST as the approach to use in repository-service interactions, the consensus was that the use of SOAP for public service interfaces, rather than being an enabling mechanism, is actually a barrier to adoption.
Whether RESTful or not, services are going to have to start having very good reasons for not offering very simple APIs over HTTP, if they are to attract the opportunistic developer.
June 9th, 2008 at 11:34 am
I suppose to some extent it is a question of what type of community you want to engage with. SOAP presumably is more attractive to those developers within an enterprise trying to get systems to integrate. More lightweight approaches are attractive to those who want to do ‘mashups’ using a variety of data sources and services on the web.
The latter approach will drive innovation and engage a wider range of developers - and this is something I believe would really help break down the ’silo’ issues we currently have.
Whether the approaches are mutually exclusive, or whether the enterprise level integration can be achieved using more lightweight approaches are two issues that we need to look at - I suspect we need both to be honest.
Just as an example, University of Michigan library has developed a RESTful interface to its library catalogue - see http://mblog.lib.umich.edu/blt/archives/2008/06/new_rest-ful_ap.html - this has been developed on top of an existing, slightly more complicated (and powerful), API (not SOAP in this case). William Dueber says in the post “[the system API] it’s based on XML, which can be confusing to deal with to the uninitiated. Remember, my focus is on weekend programmers, maybe just writing javascript inline in an HTML document.”
June 16th, 2008 at 8:24 pm
Is there an argument for non-RESTful, non-SOAP HTTP API’s?