Hacker News Reader

Comment by petrohi | Hacker News Reader

Consideration for not using HTTP status codes was that they are not working very well with JSONP-type integration. This is when page JavaScript adds "call" script object to DOM and then expects call back when it's loaded. To pass error information in this case we need HTTP server to return 200.

View on HN

If you are using jsonp (?callback=foo) then return a 200 and embed the response code in the response.

  foo({"err":{"code":500,"msg":"oh no. i broke!"},"response":null})

  foo({"err":null,"response":"hooray"})

If not using jsonp, then use the status codes IETF gave you. ;)

Most frameworks (WSGI, Rack) allow you to wrap the response and check for presence of the callback, and transform into a friendlier jsonp format. Then you can simply ignore it and code as normal. In this case, doesn't express (seems to be what you are using?) support route middleware too?

I agree here. Inspecting the response data is often easier and rarely harder than the HTTP code.

Just because REST says you should do it one way doesn't mean you should.

Reply on news.ycombinator.com