You're right, it should return JSON. It's a bit of a bug, and a bit of an undocumented feature =)

For task notes and comments, we pay some attention to the client request's Accept header. If it indicates that "text/html" is acceptable, then we return HTML -- this is intended as a convenience for client applications (such as our iPhone app) that e.g. want to drop the HTML directly into a browser UI control. The HTML returned is rewritten so that embedded images are instead hyperlinked thumbnails, suitable for small screens and limited bandwidth.

Now, the bug is that we should return "application/json" as the default format if you've specified "*/*" as your Accept header (or nothing at all), since this would be consistent with the behavior in the rest of the API.

We'll fix this in an upcoming release; meanwhile (or even after the fix...) you can workaround with an explicit Accept header on your request and get the "always JSON, all the time" behavior you expect.

There isn't currently a hook in the API to return plaintext for the note (or comment) but it makes sense to wire it up (for accepted content-type "text/plain"). We already generate such a plaintext format for our emailed reports (if you have a plaintext email client), so it's just a matter of exposing it in the API. I'll see if I can sneak it in along w/the bugfix.

Edit: We do return a plain_text attribute in the comment JSON, whose value has HTML tags stripped. I'll also add a similar attribute to the note JSON.