[ 
https://issues.apache.org/jira/browse/CAMEL-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17904945#comment-17904945
 ] 

Chamodya Dias commented on CAMEL-21478:
---------------------------------------

Of course, let me explain.

 

Current Implementation:

Let's imagine an Open API spec as follows:
{code:java}
openapi: 3.0.3
info:
  title: Simple API
  description: A minimal example of an OpenAPI specification.
  version: 1.0.0
paths:
  /example:
    get:
      summary: Get example data
      description: Returns a simple example object.
      responses:
        '200':
          description: Successful response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Product'
components:
  schemas:
    Product:
      type: object
      properties:
        id:
          type: string
          description: Unique identifier
        message:
          type: string
          description: A simple message
 {code}
The current implementation scans the packages and finds any classes with the 
name `Product`. (ex: com.example.myapp.model.Product` and it cannot match any 
other class names.

 

Problem:

There can be a requirement where you need to use a different name for the class 
rather than the schema name.

Ex: Schema can be `Product` in the API spec for the API consumers to view and 
understand, but the actual Java class used in the API implementation may be 
`ProductResponseDto` .

There can be scenarios where some teams have specific naming conventions for 
API specs and their code, so a custom class name might be required.

 

Suggestion:

What I'm suggesting is, to add an optional feature where you can use the 
`title` property of the schema object to put the actual Java class name. This 
can be an alternative flow to the current implementation, which scans the 
packages using either the schema name or title of the schema.

 
{code:java}

..
...
components:
  schemas:
    Product:
      type: object
      title: ProductResponseDto
      properties: 
...
...{code}
 

 

I agree this is a minor improvement, but it can be helpful.

> camel-rest-openapi: Input and output types binding to java classes using $ref 
> or title of the schema
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-21478
>                 URL: https://issues.apache.org/jira/browse/CAMEL-21478
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-rest-openapi
>    Affects Versions: 4.8.0, 4.8.1
>            Reporter: Chamodya Dias
>            Priority: Minor
>             Fix For: 4.10.0
>
>
> Currently, camel resolves the Java class names for RestBindingConfiguration 
> from Schema XML attribute.
> Implemented at: org.apache.camel.component.rest.openapi.RestOpenApiProcessor
> ```
> private RestBindingConfiguration createRestBindingConfiguration(Operation o) 
> throws Exception {
> ...
> ...
> Schema s = m.getValue().getSchema();
> // $ref is null, so we need to know the schema name via XML
> if (s != null && s.getXml() != null) {
> String ref = s.getXml().getName();
> ...
> ```
>  
> But the documentation says Camel can resolve the schema from the schema name: 
> [https://camel.apache.org/manual/rest-dsl-openapi.html#_binding_to_pojo_classes]
>  
> This improvement suggests adding an `else-if` condition that to above code 
> that uses `$ref` to resolve the schema name if available and another 
> `else-if` condition that uses the `title` attribute 
> (https://github.com/OAI/OpenAPI-Specification/blob/3.0.2/versions/3.0.2.md#schema-object)
>  of the schema to get the class name if available.
>  
> Also, the current implementation doesn't resolve class names when using the 
> `requestBodies` component directly in the OAS. It only uses `content` 
> attribute.
>  
> example:
> ```
> requestBody:
>   $ref: '#/components/requestBodies/createProduct'
> ```
> This improvement suggests the capability to add this also.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to