Decide a consistent approach for error handling

[ericlu88]

Right now in our request/response code we use http status code to negotiate the errors with client. This approach won't work for cases where we encounter errors in the middle of the request, since we are sending the data received from underlying session right away(not buffering).

The two possible approaches are:

• Buffer the response until the last bit and then send the data in 1 trunk, so that we could leverage the http status code.
• Always send 200 as http status code and leverage the status field in the response body to indicate the status of the response.

Open to discussion, the goal is to come up with a consistency approach for our server.

[yupinghu]

Buffering is bad, possibly unacceptable as a general approach since we can have extremely large response data. So at a high level, my feeling is:

• If it's an error we can tell before we even start getting data from the API, generate a 4xx response (or 5xx if appropriate but I hope that'd be rare).
• If the very first chunk from the API indicates an error, we should consider whether we can make a 4xx/5xx here (but it's ok to also use the next strategy).
• If we get any valid data back from the API, then always return a 2xx. If we get an error in a later chunk, try to return as much valid data as possible and then set a property of the response (status, probably) to indicate what went wrong.

[ericlu88]

For the second bullet point, I will prefer using the 3rd strategy of sending 2xx error for consistency purpose(the request-handler code doesn't need to differentiate between the first chunk or the following).

[ericlu88]

Change my thought on the second point. Will let res.sendError figure out whether we are at the first chunk or not. Doing this will be more beneficial when we land #79 so we could infer the http code out of the error type.