Software development. And stuff.

The latest version of FishEye now has a REST API (oh and an XML-RPC API too, which is less interesting).

I’m happy partly because FishEye is a great tool and this will allow integration with other tools – things we are seeing more and more with its natural friends like JIRA, DamageControl and Confluence.

But what I’m really glad to see is that they made the decision to go with REST rather than just stick with the usual suspects SOAP or XML-RPC. Looking at the actual API for FishEye, REST seems like a no-brainer as all of the calls are queries.

On the last system I worked on, we were struggling with SOAP and switched to a simpler REST approach. It had a number of benefits.

Firstly, it simplified things greatly. With REST there was no need for complicated SOAP libraries on either the client or server, just use a plain HTTP call. This reduced coupling and brittleness. We had previously lost hours (possibly days) tracing problems through libraries that were outside of our control.

Secondly, it improved scalability. Though this was not the reason we moved, it was a nice side-effect. The web-server, client HTTP library and any HTTP proxy in-between understood things like the difference between GET and POST and when a resource has not been modified so they can offer effective caching – greatly reducing the amount of traffic. This is why REST is a more scalable solution than XML-RPC or SOAP over HTTP.

Thirdly, it reduced the payload over the wire. No need for SOAP envelope wrappers and it gave us the flexibility to use formats other than XML for the actual resource data. For instance a resource containing the body of an unformatted news headline is simpler to express as plain text and a table of numbers is more concise (and readable) as CSV.

REST is something I hadn’t really considered until recently and is by no means a golden-hammer, but in our case it worked out better than SOAP and XML-RPC.