(Note: this food for thought based on an internal dicussion)<p>Overall, I think we (web developers) are often trying to cram functionality that belongs to the Application Layer (actions, events, data flows, etc.) into Transport Layers like the "holy" HTTP Protocol. This forces us to model our logic into HTTP ways of thinking like CRUD, REST and passive states.<p>Take for example, HTTP status codes. When "My App" cannot perform an action because it couldn't connect to an external API, or it couldn't perform some Magic Sauce on an object, the error that results should belong to the Application Layer, and should not be any of the Transport Layer's business. Trying to figure out status codes for these kind of failures I think is wrong.<p>With new practices like SocketIO, HTTP becomes nothing more than a Transport Layer. SocketIO is responsible for making your browser-side communicate with the server-side (or any other node) as real-time as possible. It does so using whatever is available in the environment (XHR-polling, JSONP polling, Websockets, Sockets in Flash, etc.). Transports like JSONP cannot even cope with HTTP status codes, JSONP is an entire new transport on top of HTTP.<p>With applications becoming more complex, more real-time and more event-driven, I think we have to move away from HTTP thinking.<p>HTTP has been great, but let's not get sentimental. The web has moved on.
HTTP is an application layer protocol and not a transport layer protocol. It has nothing whatsoever to do with the transportation work that networking entails - those jobs rightly belong lower in the stack.<p>If its error handling doesn't work for you, either write your own application protocol or use an existing one that fits your needs better.