For example, imagine the document at /foo/bar has moved to /new-api/foo/bar. Well, if you use HTTP for status, the server sends a 302 redirect when you try to request /foo/bar, and the user agent automatically grabs /new-api/foo/bar. If we reinvent this wheel for some reason, you can't use HTTP clients anymore, you have to use some proprietary bullshit client instead.
No thanks. This is not a problem and it does not need a "solution".
(I also agree about 204 responses for DELETE requests. The thing is gone, why does any data need to be sent back other than, "yeah, it went away"?)
The charm of JSON, to me, is its simplicity: that it can run on a bare HTTP server without worrying about dispatching, using a special library with a schema to strictly format responses, and so on.
Accepts: application/json
Please, people: REST does not simply mean "HTTP is involved somewhere".
I don't know if this proposal is optimal (smarter guys than me can decide that). But I know that a standard way of communicating application-specific errors would be a big step forward.
A year ago I searched for an adequate in-place editing plugin for Rails that didn't require major surgery to provide error messages to the user. I was surprised at the complexity required to handle a simple error condition. Usually Rails has all the goodness baked in but it seems application-specific status messages with JSON are out of scope. I asked "How to show server errors in Rails with JSON and jQuery" [1] on Stack Overflow and it's received more views than any other question I've ever asked.
[1] http://stackoverflow.com/questions/2489567/how-to-show-serve...
HTTP/1.1 422 Unprocessable Entity
{"error": "email address must contain @", "applies_to": "email_field"}
In response to there being no method of feedback, looks like the mailing list is linked up now: http://lists.omniti.com/mailman/listinfo/jsend-users
While I might no agree with everything presented in the project, I do agree that it is somewhat arbitrary (and certainly complex) mapping HTTP status codes into every JSON API.
Unfortunately, this spec doesn't address that at all as far as I can tell :(
{ "post" { "id" : 1, "title" : "A blog post", "body" : "Some useful content" } }