I have implemented a logic for Response in my Web API projects, and response object looks like this:

public class Response
{
    public bool IsSuccess { get; set; }
    public object Data { get; set; }
    public string Message { get; set; }
}

• IsSuccess indicates whether the call is success or failure.
• Data to be used for further processing when IsSuccess is true
• Message to be used for further processing when IsSuccess is false

I have few questions in mind. Please help me with this.

• Is it ok to use custom objects over the status codes?
• What disadvantages this approach will it have?
• Should I switch to status codes / ControllerBase return methods instead?

CodePudding user response：

HTTP has standardized the structure for representing request and response. To that extent, a response has 3 parts - Status, Headers & Body. Please refer here. Each part has a definite purpose. Since the question is on status codes, I'll restrict myself to it.

The primary purpose of status codes is to indicate whether the request has been processed correctly or not. The automation systems and scripts depend on it for branching their decisions.

It is important to remember that the model defined will be part of the response body. This means that the framework API is built on will still include a default response code - usually, it's a 200 OK. If the IsStatus attribute is supposed to act as a replacement for the Status code, if proper care is not taken, the status code and IsStatus may show different values when the API errors out.

Finally, I think you are better off representing an ErrorResponse instead. Something in the lines of -

public class ErrorResponse{
    // Application or Service specific code 
    // to identify the error
    public string Code {get; set;}

    // A link to detailed description of the
    // of the error
    public Uri Info {get; set;}

    // A high level friendly message about the
    // error
    public string Message {get; set;}
}

CodePudding user response：

HTTP status codes are a standard. See e.g. this docu. Nobody is expecting to get a 200 OK with IsSuccess set to false, because 200 OK is a success. 3xx are redirects, 4xx are client errors, 5xx are server errors. Stick to that, do not reinvent the wheel, you'll confuse the clients of your API.

However, you can and it's a good practice to include more custom information into your response. Define your response e.g. like this:

public class ErrorDetails
{
    public string Message { get; set; }
}

Than set the response code directly on the response object of .net, not on your own:

var error = new ErrorDetails { ... };
context.Response.StatusCode = 4xx / 5xx; // and not 200, it's an error! context is HttpContext
await context.Response.WriteAsync(JsonConvert.SerializeObject(error));

Controller methods already have build-in methods for this, so no need to do it the hard way as in the example above either. E.g.:

this.BadRequest(error);

This will set a 404 on the response object and pass your error object in the payload as additional data. There is this.Ok() and a bunch of other methods for each situation.