-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Payload contentNegotiation case for modular #2497
Comments
Basically, the problem here is how to handle overload so that the constant type headers can accept custom values. For this case, their typespec are defined as namespace DifferentBody {
model PngImage {
@header contentType: "image/png";
@body image: bytes;
}
model PngImageAsJson {
@header contentType: "application/json";
content: bytes;
}
@sharedRoute
op getAvatarAsPng(@header accept: "image/png"): PngImage;
@sharedRoute
op getAvatarAsJson(@header accept: "application/json"): PngImageAsJson;
} RLC generate the code as export interface DifferentBodyGetAvatarAsPng {
get(
options: DifferentBodyGetAvatarAsJsonParameters,
): StreamableMethod<DifferentBodyGetAvatarAsJson200Response>;
get(
options: DifferentBodyGetAvatarAsPngParameters,
): StreamableMethod<DifferentBodyGetAvatarAsPng200Response>;
}
export interface Routes {
/** Resource for '/content-negotiation/different-body' has methods for the following verbs: get */
(path: "/content-negotiation/different-body"): DifferentBodyGetAvatarAsPng;
}
export type ContentNegotiationContext = Client & {
path: Routes;
}; In RLC layer, there's no problem to provide a third undefined value here for accept header, we can just use as any cast. const result = await client
.path("/content-negotiation/different-body")
.get({ headers: { accept: "wrongAccept" } as any });
assert.strictEqual(
(result.body as any).message,
"Unsupported Accept header"
); but in Modular, if we want to accept customer self defined header value, export function _getAvatarAsPngSend(
context: Client,
options: DifferentBodyGetAvatarAsPngOptionalParams = { requestOptions: {} },
): StreamableMethod<DifferentBodyGetAvatarAsPng200Response> {
return context
.path("/content-negotiation/different-body")
.get({
...operationOptionsToRequestParameters(options),
headers: {
accept:
options.requestOptions?.headers?.["accept"] ?? "image/png" as any,
},
}) as StreamableMethod<DifferentBodyGetAvatarAsPng200Response>;
} Since the accept header could be other values than "application/json" and "image/png", type inference system somehow thinks we are trying to convet Proposal 1: Pros:
Cons:
Proposal 2: Pros:
Cons,
Proposal 3: Cons:
|
we should go for proposal 3 and maybe log a warrning if possible. |
The text was updated successfully, but these errors were encountered: