Return HttpResponse object to chain methods

[omar-mohamed-khallaf]

Is your feature request related to a problem? Please describe.
I've seen a continuous pattern in my code where I create the HttpResponse and then set the status code to return a response like:

Json::Value jsonResponse;
jsonResponse["err"] = "content-type is not application/json";

auto httpResponse = drogon::HttpResponse::newHttpJsonResponse(jsonResponse);
httpResponse->setStatusCode(drogon::k400BadRequest);
callback(httpResponse);

Describe the solution you'd like
Wouldn't it be much nicer if we could write it as:

Json::Value jsonResponse;
jsonResponse["err"] = "content-type is not application/json";
callback(drogon::HttpResponse::newHttpJsonResponse(jsonResponse)->setStatusCode(drogon::k400BadRequest));

and the same for headers:

callback(drogon::HttpResponse::newHttpJsonResponse(jsonResponse)
    ->addHeader("Example-Header-1", "value")
    ->addHeader("Example-Header-2", "value")
    ->addHeader("Example-Header-3", "value")
    ->addHeader("Example-Header-4", "value"));

These methods return void so I don't think they will break the API consistency, am I right?

[rbugajewski]

Thanks for your ideas!

As returning errors as JSON payload is not standardized (but there are certainly enough implementations out there that use it that way), personally I would have written a helper function, or even keep a global JSON bad request response, so that it could be reused.

I think I may see what you are trying to achieve here, but I think it is more of a cosmetic nature, or doing things in a different way.

In my opinion there should not be different interfaces for basically the same behavior, as this will cause confusion for framework users. I rather prefer a sanctioned way. I think this kind of changes would fit best into the Drogon 2.0 release cycle where we have the chance to introduce API breaking changes.

We already have issue #682, and #806 for API breaking changes. I think this open discussion better fits at these places.

[omar-mohamed-khallaf]

Great, should I close this issue ?

[rbugajewski]

Sure, feel free to close it, as it should be already referenced in the other two issues 😄