HN Explorer

Hack your finances with Buxfer's API

18 points by ashu ↗ HN
We have created a special account (apidemo:apidemo) so you can play around with the API. For example, just try:

https://apidemo:apidemo@www.buxfer.com/api/analysis.html?month=feb08

Read more about it at: http://www.buxfer.com/blog/2008/03/02/introducing-the-buxfer-rest-api/

Let us know what you think!

5 comments

[ 2.0 ms ] story [ 25.5 ms ] thread
bjclark
As Paris would say, HOT.

Kudos for the real REST api, not a "REST Like" bullshit api. :)

Xichekolas
Amen on the REST api...

Just wondering if it will throw back http response codes like 403 for forbidden and such or if it will always give 200 and then the error in the xml/json itself?

Also, are you planning on opening up POST/PUT verbs on things like Groups/Contacts so I can add those through the API as well? From what I can gather you can only list them currently.

ashu
Hm. good point about the HTTP response codes vs. error within xml/json. Currently, it does not produce 403 codes, and provides all error indications only in the XML/JSON data returned. In my view, it makes stuff more uniform to handle and easier to program. (For example, instead of checking for both the HTTP codes _and_ the content, i can just parse the JSON directly, and check response.status... ) Is there something I am missing? I would love to stand corrected.

Regarding groups/contacts, we can consider adding POST/PUT verbs on them; sure, but I am wondering about the utility. It seems to me that the adding contacts or groups would be a very rare (sort of 1-time) activity, unless you are planning to build a completely new skin for Buxfer :) Thoughts?

Xichekolas
For the error codes, I think it just really depends on your client library. I wrote up a client library in Ruby that just throws standard exceptions on things like a 403, so if you give back a 200 even with errors, it means I'll have to make sure and check for those in the xml file.

I'm not really sure either way is better than the other, I just had something already that noticed things like 403 and 400 (wrote it testing against S3) and threw exceptions accordingly, so, assuming all the REST services out there throw 403 when access is denied, I could be lazy and use (roughly) the same general client to talk to buxfer as I did for S3.

On the other hand, I definitely see your point that HTTP error codes don't really map 1-to-1 to all the possible errors a service could give back, so they can be kind of redundant.

For the post/put on contacts/groups... I was just thinking about scripts to mass import contacts from different places. You guys probably already have a way to do that though, at least for the most important places like gmail/facebook. I guess I just like the idea of giving as many options as possible in the API, because you never know what people will end up doing with it.

(To summarize, don't assume I have a real use case for this stuff, I'm just a nerd and like to throw out possibilities.)

ashu
403 response codes: good point. We now send 403s if there's an error. However, even then the response-text is sent encoded as

  { response: { status: "Error: ... " } }
Hope this works for you.

Regarding the POST/PUT for contacts, your use case is reasonable enough (and very good for us :) Also, the whole point of an API is to enable new use cases which we can't think of! We will open up modifications of tags / contacts / groups / etc. in our next update.