JSend: a specification for how JSON responses should be formatted

The case for not using HTTP status codes (and thus breaking the cacheability and layering which are key to the REST model) is very weak. I just don't see why it all has to be wrapped in so many layers. GET /posts.json should return a list, GET /posts/1.json should return an object, and DELETE /post/1.json should result in a HTTP 204 if successful. In the case of errors, the response's status code and an object with exception information should suffice.

Sure, HTTP status codes should be used. But they aren't enough to communicate application-specific messages from an app backend to an AJAX front-end. For example, AJAX on the browser might submit a form and the server returns a 422 (HTTP validation error status code). How will you be able to inform the user that the "email address must contain @" or "foobar is not an acceptable name"? You need to consume some JSON that has a payload of application-specific status messages.<p>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.<p>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.<p>[1] <a href="http://stackoverflow.com/questions/2489567/how-to-show-server-errors-in-rails-2-3-5-with-json-and-jquery" rel="nofollow">http://stackoverflow.com/questions/2489567/how-to-show-serve...</a>

I think many are overlooking the fact that this is already common practice. This spec. is just trying to make the practice less bad, not worse.<p><a href="http://code.google.com/apis/websearch/docs/#fonje" rel="nofollow">http://code.google.com/apis/websearch/docs/#fonje</a><p><a href="https://www.dropbox.com/developers/docs" rel="nofollow">https://www.dropbox.com/developers/docs</a>

Congrats, you just re-invented SOAP!

Enjoying the discussion. The argument that HTTP status codes are "good enough" is one perspective. While I don't buy into everything in the "spec" proposed here, I think having application specific errors that make more sense is reasonable.<p>In response to there being no method of feedback, looks like the mailing list is linked up now: <a href="http://lists.omniti.com/mailman/listinfo/jsend-users" rel="nofollow">http://lists.omniti.com/mailman/listinfo/jsend-users</a><p>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.

The one thing I could see this being useful for is standardizing pagination for large result sets. Ideally, the server would return meta pagination information that includes total number of results, offset, limit, etc.<p>Unfortunately, this spec doesn't address that at all as far as I can tell :(

It appears there is no way to contact the author for feedback. This is not how specs work.

This is exactly what SOAP tried to do. I suggest sticking to HTTP Status codes.

Why not just return NULL on failure and the data object on success? in most cases that will work, in some cases it will not be enough, but why add redundant data to all responses?

This is not JSON. I don't know what it is.<p><pre><code> { "post" { "id" : 1, "title" : "A blog post", "body" : "Some useful content" } }</code></pre>