Settings and activity
1 result found
-
223 votes
We’re closing this request out and asking that developers suggest or vote for the specific features you’re after as it’s easier to get feedback to you on each request this way and also free up your votes. I’d like to reassure you we’re committed to offering the best API we can.
Tony Rule
Product Manager, Xero Developer APIAn error occurred while saving the comment
This is an excellent discussion but there are lots of points made here so I'll try to address the ones that seem the most pertinent.
First of all - we do have a dedicated team and our public API is key to our goal of becoming the accounting engine for the cloud. Our CEO recently blogged about this strategy (http://blog.xero.com/2010/08/best-of-breed-v-all-in-one/). If we're going to integrate with best of breed applications then we need to have the API to cope with that. For example, every product feature discussion includes how the API is affected or how the API should work. Obviously everyone has feature requests for the API and our team are working on them. To be honest we also have deal with the general resource juggling that any start-up has to do so sometimes the API release cycle slows down more than we'd want it too - but it's not a second-class citizen even if it appears that way.
Which nicely leads into the architectural discussion regarding how we should build our app. While it seems like the ideal design for a fledging API is to build it completely open and make the web app a consumer of it, we needed to make architectural decisions around usability, performance, security, maintainability and speed to market which meant it wasn't feasible for us to design the Xero development framework in this way. We've definitely litigated this decision in retrospect, and over time we've moved to a more loosely coupled architecture internally that utilizes more internal web services. However opening these up is not feasible for lots of reasons (the non-functional ones above being the chief of them). Our internal API is very complex - our design team has done a great job of making the complicated simple in the UI, but the complexity still exists - it just exists in the back-end where it belongs.
When we made those initial architectural decisions we made them with a public API in mind. It was on the first feature roadmap - it's been a goal from day 1. But the best way we saw to do this was to provide a restful API that exposes what is essentially a programmable user interface. Simplicity, security & performance are all key. Even though we expose some of our schema to developers there is still a lot that's going on behind the scenes - all that's missing with our public API is the pretty UI that we've developed for our customers, so that you can provide one to yours while still accessing our accounting engine.
So coming back to the basic question will we expose everything via the API? Absolutely. But it won't happen overnight. Even if we had the entire team working on it we'd still need a feature roadmap to work towards. So what are the burning features that you believe will make your integration better? Or the features that are lacking for you to even start? How do we start to make this better for you guys?
Craig
CTO