OpenAPITools / OpenAPITools/openapi-generator

[BUG][cpp-restsdk client] Multiple response schemas not supported

Open
#9,376 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue: Bug
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Description

I believe OpenAPI allows us to create APIs with multiple response Schemas, which was debated to death in this ticket: https://github.com/OAI/OpenAPI-Specification/issues/270. I'm asking for support in cpp-restsdk, since my API is born of some compexity that we can't easily handle using the current implementation effectively.

openapi-generator version

openapi-generator 5.0.1.0

OpenAPI declaration file content or url
  /complexResponse:
    get:
      summary: Checks the status of a feature
      responses:
        200:
          description: The feature has completed
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/didStuff'
        202:
          description: feature is at work
        412:
          description: you are not ready for this feature
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/errorObj'
components:
  schemas:
    didStuff:
      type: string
    errorObj:
      type: object
      properties:
        error:
          type: string
Steps to reproduce

So here's some googleTest I'd have to write to test the 3 responses:

TEST_F(tryMe, complexApiTest) 
{
	std::shared_ptr<ApiConfiguration> apiconfiguration = std::make_shared<ApiConfiguration>();
	apiconfiguration->setBaseUrl(utility::conversions::to_string_t("http://127.0.0.1/api/default"));
	std::shared_ptr<ApiClient> apiclient = std::make_shared<ApiClient>(apiconfiguration);
	std::shared_ptr<myApi> api = std::make_shared<myApi>(apiclient);
	try
	{
		api->complexResponse().then([&](std::shared_ptr<didStuff> result){
                      std::cout << "well the main stuff worked" << std::endl;
                }).wait();
	}
	catch (const ApiException& e)
	{
		std::cout << e.what() << std::endl;
		std::string s(std::istreambuf_iterator<char>(*e.getContent()), {});
		utility::string_t localVarResponse = utility::conversions::to_string_t(s);
		web::json::value localVarJson = web::json::value::parse(localVarResponse);
		std::shared_ptr<PreconditionsResponse> test = std::make_shared<errorObj>();
		test->fromJson(localVarJson);
                std::cout << "our 412 was presumably hit" << std::endl;
	}
	catch (const web::json::json_exception& e)
	{
		std::cout << "we can only assume that we returned a 202 which has an empty response" << std::endl;
	}
}
Related issues/PRs

https://github.com/OAI/OpenAPI-Specification/issues/270

Suggest a fix

Somehow creating multiple pplx tasks in the api-source.mustache might work for us. Overriding {{#operation}} for each schema would be an interesting find. If we would have to put in n amount task callbacks as our swagger specifies, that would be ideal.

BUT AT THE VERY LEAST, moving the response code that throws an ApiException needs to be raised from 400 to 500 in api-source.mustache line 279.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with modules/openapi-generator/src/main/resources/cpp-rest-sdk-client/api-source.mustache, especially the response handling around line 279, and compare it with the supplied OpenAPI declaration. Use the generated client and the proposed GoogleTest scenario to examine 200, 202, and 412 responses. Done means the generated cpp-restsdk client supports the declared response schemas and status codes with regression coverage.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, openapi
Domain
api, tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.