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.)
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.
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.)