Read-onlyness was a design choice at the time and still has its place. The main problem with the API is that it's too low-level—you have to do a bunch of work to reconstruct what actually shows up on an HN page. The next version of the HN API will give a simple JSON representation of each HN URL. Initially it will still be read-only though; then we'll see about whether to extend it to writes.
Sorry, didn't mean admitting to "absolute garbage" in a literal way. Mostly referring to statement such as:
> I'm not saying this to defend it - It's not the ideal public API, but it's the one we could release in the time we had. While awkward, it's possible to implement most of HN using it.
My words may have been a bit too harsh but I still think I have a point. The only thing I could find use of the API was to get the user's details (karma, description, date created etc). Other than that, I ended up relying on scraping.
Unfortunately, unless the JSON api offers write access, it won't be of much use for my app's use cases. Lets just hope the JSON Api isn't going to break anything major in the HTML of the site and there aren't any major re-designs of the site in the pipeline.
Read-onlyness was a design choice at the time and still has its place. The main problem with the API is that it's too low-level—you have to do a bunch of work to reconstruct what actually shows up on an HN page. The next version of the HN API will give a simple JSON representation of each HN URL. Initially it will still be read-only though; then we'll see about whether to extend it to writes.