Comments on: The opportunistic developer is allergic to soap http://blog.paulwalk.net/2008/06/09/the-opportunistic-developer-is-allergic-to-soap/ Fri, 05 Dec 2008 09:18:52 +0000 http://wordpress.org/?v=2.6.2 By: Tom Hoffman http://blog.paulwalk.net/2008/06/09/the-opportunistic-developer-is-allergic-to-soap/#comment-1037 Tom Hoffman Mon, 16 Jun 2008 20:24:23 +0000 http://blog.paulwalk.net/2008/06/09/the-opportunistic-developer-is-allergic-to-soap/#comment-1037 Is there an argument for non-RESTful, non-SOAP HTTP API's? Is there an argument for non-RESTful, non-SOAP HTTP API’s?

]]> By: Owen Stephens http://blog.paulwalk.net/2008/06/09/the-opportunistic-developer-is-allergic-to-soap/#comment-1030 Owen Stephens Mon, 09 Jun 2008 11:34:28 +0000 http://blog.paulwalk.net/2008/06/09/the-opportunistic-developer-is-allergic-to-soap/#comment-1030 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." 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.”

]]>