REST and HTTP services as a business advantage

The advantages of HTTP as an application protocol (not just a transport) as opposed to many other networked service models are not abstract, idealized technical advantages.  They directly affect your—and your partners’—cost of doing business.

At Basho, our services integrate out of necessity with those of many kinds of partner companies, including CRM, Business Intelligence, Search, and more.  We consider ourselves lucky in general when a company we’d like to partner with exposes any consistent and documented interface for this purpose.

However, when those interfaces are SOAP or another RPC-shaped system it means that each integration is a fairly major new project even when the resulting connections between applications are conceptually small.  This is because you have to learn the programming model of that other service and work as though you were a developer of that service—learning their calling conventions, naming schemes, error conditions, and so on.

We recently had the pleasure of integrating with Jigsaw‘s data service.  While they don’t quite match up to the ideals of REST just yet, their service is young and the interface is already far better than that of many other business-to-business integration APIs.  Not only did they deliver a cleaner and easier service than expected, I suspect that they did so at lower cost than many others.  How?

By using HTTP.

Even the coarsest approximation of the Web’s uniform interface gives you a much better running start than is possible with, say WSDL and SOAP.  Jigsaw’s Web interface isn’t perfect (GET requests are idempotent but not safe, and a couple of status codes are incorrectly used) but it is simple and it isn’t surprising.  The fact that there is already a completely interoperable client in every major programming language means that, instead of using some WSDL to generate 10,000 lines of code to then put a client on, we were able to just jump in and immediately write working client code.  The resulting client code was also about 20% as long as the manually written portion of our client code in comparable services that use SOAP.

I’m not talking about ideal systems, and I’m not talking about idealistic academic goals.  I’m just talking about the simple realities of how your technical choices affect the level of effort that your partners must apply in order to work with you.  That simple reality has a direct and powerful effect on the bottom line.

Comments

Thanks. Good points.

Any pointers to best practices for organizations looking to create open APIs for their applications?

I have a few organizations I would love to push towards best practices in this area.

Posted by Frank Daley on 08 Jun 2009 at 02:28

The pointers are what this article is all about. By using a REST-ful API you can provide a simple interface to your data. The barrier to entry for business partners is much lower.

Simply do some research on providing a REST-ful API (URLs represent objects/nouns, access is provided using the 4 HTTP verbs). As stated in this article, even the worst REST-ful implementation is leaps and bounds ahead of a complex SOAP interface.

Posted by Chris M. Welsh on 28 Jun 2009 at 14:52

Add comment