jhannes / openapi-generator-typescript-fetch-api

TypeScript client library using Fetch API and API interfaces
13 stars 6 forks source link

Improved support for multiple response types/204 no content #10

Open EventuallyEven opened 3 years ago

EventuallyEven commented 3 years ago

Given the following definition

"/someurl": {
  "get": {
    "operationId": "someId",
    "tags": ["tag"],
    "parameters": [
      {
        "name": "thing",
        "in": "path",
        "required": true,
        "schema": {
          "type": "string"
        }
      }
    ],
    "responses": {
      "200": {
        "description": "Yes",
        "content": {
          "application/json": {
            "schema": {
              "$ref": "someschema"
            }
          }
        }
      },
      "204": {
        "description": "Empty"
      }
    }
  }
}

we get the following interface method in the api

someId(params: {
        pathParams: { thing: string };
    }): Promise<someschema>;

The ACTUAL values that can be returned are someschema OR a Response object with status 204. It would be preferable for the api to reflect this, or, even better, if the actual return value was someschema or void, i.e.

someId(params: {
        pathParams: { thing: string };
    }): Promise<someschema | void>;
jhannes commented 3 years ago

Currently, the following operation will potentially throw an exception:


"/someurl": {
  "get": {
    "operationId": "someId",
    "tags": ["tag"],
    "parameters": [
      {
        "name": "thing",
        "in": "path",
        "required": true,
        "schema": {
          "type": "string"
        }
      }
    ],
    "responses": {
      "200": {
        "description": "Yes",
        "content": {
          "application/json": {
            "schema": {
              "$ref": "someschema"
            }
          }
        }
      },
      "400": {
        "description": "An error occurred"
      }
    }
  }
}```

It may be hard to support the 204 case without making the 400-case worse. What are your thoughts?
EventuallyEven commented 3 years ago

Ideally, error codes would not result in a thrown exception, but a rejecteded promise, regardless of what is declared as possible responses.

Alternatively, maybe any method with JSON as a possible result should result in

`someId(params: {

}): Promise;` This is more correct as handleResponse is `if (contentType && contentType.startsWith("application/json")) { return response.json(); } return response;`
jhannes commented 3 years ago

Partially implemented this in 7b8c0319