

Hack your finances with Buxfer's API - ashu

We have created a special account (apidemo:apidemo) so you can play around with the API. For example, just try:<p>https://apidemo:apidemo@www.buxfer.com/api/analysis.html?month=feb08<p>Read more about it at: 
http://www.buxfer.com/blog/2008/03/02/introducing-the-buxfer-rest-api/<p>Let us know what you think!
======
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.

