3 ms·
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" scri
by petrohi 15y ago
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.
- jmathai 15y agoI 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.
- stock_toaster 15y agoIf 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?