Provide nil return support for the client generation when the response has no content type instead of giving http:Response

[lnash94]

Description:
Currently, we are generating the http:Response when the OAS has a response with no content. With this fix we suppose to generate nil type instead of giving http:Response.

calendars/{calendarId}:
    delete:
      ...
      responses:
        "200":
          description: Successful response
      security:
        - Oauth2:
            - https://www.googleapis.com/auth/calendar
          Oauth2c:
            - https://www.googleapis.com/auth/calendar
      tags:
        - calendars
      

current generated code

remote isolated function deleteCalendar(string calendarId, "json"? alt = (), string? fields = (), string? 'key = (), string? oauth_token = (), boolean? prettyPrint = (), string? quotaUser = (), string? userIp = ()) returns http:Response|error {
        string resourcePath = string `/calendars/${getEncodedUri(calendarId)}`;
        map<anydata> queryParam = {"alt": alt, "fields": fields, "key": 'key, "oauth_token": oauth_token, "prettyPrint": prettyPrint, "quotaUser": quotaUser, "userIp": userIp};
        resourcePath = resourcePath + check getPathForQueryParam(queryParam);
        http:Response response =  self.clientEp->delete(resourcePath);
        return response;
    }

suggested code :

remote isolated function deleteCalendar(string calendarId, "json"? alt = (), string? fields = (), string? 'key = (), string? oauth_token = (), boolean? prettyPrint = (), string? quotaUser = (), string? userIp = ()) returns error? {
        string resourcePath = string `/calendars/${getEncodedUri(calendarId)}`;
        map<anydata> queryParam = {"alt": alt, "fields": fields, "key": 'key, "oauth_token": oauth_token, "prettyPrint": prettyPrint, "quotaUser": quotaUser, "userIp": userIp};
        resourcePath = resourcePath + check getPathForQueryParam(queryParam);
        return self.clientEp->delete(resourcePath);
    }

Describe your problem(s)

Describe your solution(s)

Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

[lnash94]

Reference issue: #5721

[lnash94]

While implementing this improvement, I encountered a scenario where there was no content type, but the headers were present in the response. https://github.com/ballerina-platform/openapi-connectors/blob/faac2bfcd2fdd54b1f838a3cf044316718411d86/openapi/azure.datalake/openapi.yaml#L896

head:
     ...
       - name: x-ms-client-request-id
        in: header
        description: A UUID recorded in the analytics logs for troubleshooting and
          correlation.
        schema:
          pattern: ^[{(]?[0-9a-f]{8}[-]?([0-9a-f]{4}[-]?){3}[0-9a-f]{12}[)}]?$
          type: string
      responses:
        200:
          description: Ok
          headers:
            x-ms-namespace-enabled:
              description: 'A bool string indicates whether the namespace feature
                is enabled. If "true", the namespace is enabled for the filesystem.  '
              schema:
                type: string
            ...
            Last-Modified:
              description: The data and time the filesystem was last modified.  Changes
                to filesystem properties update the last modified time, but operations
                on files and directories do not.
              schema:
                type: string
            x-ms-properties:
              description: The user-defined properties associated with the filesystem.  A
                comma-separated list of name and value pairs in the format "n1=v1,
                n2=v2, ...", where each value is a base64 encoded string. Note that
                the string may only contain ASCII characters in the ISO-8859-1 character
                set.
              schema:
                type: string
            x-ms-request-id:
              description: A server-generated UUID recorded in the analytics logs
                for troubleshooting and correlation.
              schema:
                pattern: ^[{(]?[0-9a-f]{8}[-]?([0-9a-f]{4}[-]?){3}[0-9a-f]{12}[)}]?$
                type: string
            Date:
              description: A UTC date/time value generated by the service that indicates
                the time at which the response was initiated.
              schema:
                type: string
          content: {}

With our suggested approach of returning nil instead of the default http:Response, there might be a loss of details regarding the headers, as mentioned here: issue comment.

To address this concern, I'm thinking that would it be possible to consider including the http:Response from the previous approach for the following 2 scenarios :

• the headers are present but the content is unavailable
• the links are present but the content is unavailable
  ( the OAS response includes three main sections in OAS: content, headers and links.)

@shafreenAnfar, @TharmiganK appreciate your thoughts regarding how to overcome this loss of detail.

[TharmiganK]

That makes sense. +1 to return http:Response when either headers or links present in the OAS