support range header for pagination

Range header current limitations

Looking to use the Range header for pagination scenarios. The header should be made available in templates as a typed object including the unit, to and from properties.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range

so far the parameter styling offers basic support but it is not serialized properly using the typescript client.

given
name: range
in: header
description: range example
required: false
schema:
type object
properties:
unit:
type: string
style: simple
explode: true

the code generated

public exampleFromOpenApiTeam(range?: object, observe: any = 'body', reportProgress: boolean = false, options?: {httpHeaderAccept?: 'application/json'}): Observable<any> {
  let headers = this.defaultHeaders;
  if (range !== undefined && range !== null) {
    headers = headers.set('range', String(range));
  }
}

the issue is that this generates [object Object]

Proposed solution

the range header should have an interface or type that serializes to the syntax as per the spec.

Range: <unit>=<range-start>-
Range: <unit>=<range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=<range-start>-<range-end>, <range-start>-<range-end>, <range-start>-<range-end>
Range: <unit>=-<suffix-length>

Approach / Design Considerations

Prior to tackling this issue ( we can tackle the fix ) we need some guidance on the approach:

• custom format extension ? are there docs and examples of this ?
• handle the header natively in the templates ? for example Content-Disposition is handled as such.

alternatives / limitations

As we want to use this for pagination and in particular in the java and typescript clients. We wan't to keep the types as opposed to generating a string. When using a string parameter in the generated client and consuming front end we lose the strong typing and transpile time contract validation with the back end.

We want to use the Range as it describes the paging mechanism with an existing header.

Currently we are using, limit / offset query params but our api design docs call for using the header.

Start by reviewing the TypeScript client parameter serialization shown in the issue and the existing native handling of Content-Disposition. Compare the desired typed Range representation with the linked HTTP specification and determine how generated Java and TypeScript clients should represent it; done means Range values serialize to the specified syntax without producing [object Object].