[Feature request] Discriminated unions on status for error or success responses

[sushruth]

How would the swagger-typescript-api team feel about having the status from the response as a typescript union discriminant where rest of the props would be defined based on its value?

For example, if the swagger.json file contains this for a given api call -

"responses": {
  "200": {
    "description": "Resource is successfully created.",
    "schema": { "$ref": "#/definitions/ResourceSuccessResponse" }
  },
  "400": {
    "description": "Create resource request has invalid fields.",
    "schema": { "$ref": "#/definitions/ErrorResponse" }
  },
  "401": {
    "description": "Create resource request has invalid user credentials.",
    "schema": { "$ref": "#/definitions/ErrorResponse" }
  },
  "409": {
    "description": "Resource name already exists.",
    "schema": { "$ref": "#/definitions/ErrorResponse" }
  }
}

hypothetically the response could be of this format -

type HttpResponseType<Status extends number, ResponseData> = {
    status: Status,
    data: ResponseData
}

type ResourceCreationResponse =
    | HttpResponseType<200, ResourceSuccess>
    | HttpResponseType<400, ErrorResponse>
    | HttpResponseType<401, ErrorResponse>
    | HttpResponseType<409, ErrorResponse>

type ResourceSuccess = {
    resource: string
}

type ErrorResponse = {
    code: number
    message: string
}

declare const a: MyApiCallResponseType;

if(a.status === 200) {
    console.log(a.data) // `a.data` is of type ResourceSuccess now
}

This could also be an option if not the default.

I would be willing to make a PR for this if this seems like a good idea. It definitely makes the resulting types stronger in my experience with slight flexibility cost.

[js2me]

Hello @sushruth ! Yes, I'm agreed with you, it should be in the some extra option and it's a good idea!
Please open PR if you can