I would recommend ditching ATOM as the spec for data transfer. There is a lot of weirdness in your library code with handling ATOM specifics that don't need to be in there (monster search and replace on Ÿ) . We began integrating with the API by writing our own library but found that trying to rollout our own and keeping to ATOM and the nuances to be too time consuming. Rolling your own library is something that should be possible with a REST based service that is as simple as yours is.
New library code would be much appreciated (at least well documented library code). Or if you get rid of ATOM and document your API really well I am sure someone will contribute a library that would make it easy to integrate against (it wouldn't take long as your software lends itself to REST based services and your objects are pretty intuitive).
Instead of ATOM, a simple XML DTD that you defined yourself, JSON or serialized PHP would seem to work better, at least from my perspective. ATOM is the wrong fit for this job, in my opinion (a lot of unused elements in the XML). But then again, I don't work for CC and don't know the ins-and-outs. I'm simply a developer who has integrated with a large amount of APIs and find CC to be one of the most painful I think I have worked with.
Hopefully this isn't coming across as a rant against CC. On the contrary, I really appreciate businesses that open up their data via web based APIs allowing their customers and communitity access to a wealth of information that 5+ years ago was unheard of. An API is something we look for when selecting any web based software vendor.
In addition, I really appreciate the RESTfullness of your API. That attribute makes it somewhat intuitive on how and where I need to request in order to get (or put) the information I need. The CC API is much better in this regard than numerous API's that claim to be RESTful but don't seem to be.
Thanks for the feedback and the kind words on our following RESTful model. We've actually tried very hard to follow that model and it has definitely been hard to do when a task would be easier if we went outside the model.
Regarding ATOM feedback, at this time I don't forsee is leaving the ATOM format. Without releasing an entirely new version of the API with a different format, it would be impossible to change that without breaking 1000s of integrations now. Certainly something we'll be looking at in a 2.0 of our APIs, however that is not a short term project. Can completely understand your points on the extra tags, though our goal was to be able to piggy back on the numberous implementations of ATOM 1.0 readers/writers that exist currently on most web development platforms. We did not intend to make that harder on developers and apologize for the side effect it had on your development.
JSON is very interesting to us and we're looking hard at it. We of course want to make developing easier for our partners and JSON would definitely do that for a good portion of our user base. Keep your eyes and ears open on our developer newsletter, I'm sure you'll be hearing more about JSON in the future as we continue to strive to make our APIs more useful and developer friendly.