Open haolingdong-msft opened 2 months ago
this issue is raising the same concern that this previous issue raised. Currently the design is that the method signature is agnostic of the protocol and serialized information, but I think we can revisit this during our scrum talk and see what new thoughts are. We're in a weird spot right now, where I feel we want to move more towards what's directly in the typespec, but we are still modifying the method signature based off of HTTP-specific info. I think it would be good to revisit this as well during out discussions later today, to see if we can get more consistency here.
Thanks @iscai-msft for the reply. Yeah, I know this issue and I totally understand the TCGC design is SdkServiceMethod
is for generating method (in Java and .Net world, it is convenient method), and SdkHttpOperation
is for generating serialization part of code. And I like the idea. But in some cases, we still need the information on SdkHttpOperation
to generate convenient method signature and imp. So I wonder if TCGC could provide a helper function to let us get Http parameter from Sdk method parameter.
Summarize on 8/29 discussion: We have three options regarding to this issue:
SdkMethodParameter
and SdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
, could be a proprety on SdkMethodParameter
.SdkMethodParameter
to SdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
, signature like getHttpOperationParameter(methodParam: SdkMethodParameter): SdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
.SdkServiceMethod
's functionality and add callbacks on SdkServiceMethod
, e.g. on parameter ordering, missed inforation on multipart/json-merge-patch etc.Personally I prefer option 2 together with option 3, we can first provide option 2, and do the enhancement/enrichment in option 3 together. /cc @iscai-msft @m-nash @srnagar @tadelesh
I agree with your summary @haolingdong-msft thank you so much! To me, 1 and 2 are about the same, but it makes sense to expose it as a helper function since not all of us need it
@iscai-msft we also need the mapping between client.initialization.properties
and path/query/header location information to build the correct RLC request in Modular.
A small point, for server endpoint parameterized host parameters, we don't want them to be mapped to path parameters.
/cc @tadelesh
Example:
TSP:
Generated java sdk:
code-model:
TCGC response:
SdkServiceMethod
'sfile_data
parameterSdkHttpOperation
'sbodyParameter
parameterIt is recommended to generate sdk's convenient method using
SdkServiceMethod
, but currentSdkServiceMethod.SdkMethodParameter
is lack of information related with body/header/query/path parameters, when you get aSdkMethodParameter
, you don't know if it's body/header/query/path parameters. But the convenient method could depend on those information. e.g.bytes
provided bySdkMethodParameter
) for the method signature and have additional handling in convenient method impl before calling protocol API;accept
andcontent-type
headers will not be added to convenient method signature;And for Java, you can see we use M4 code-model as intermediate output,
ConvenientApi.parameters
contain information likehttp.in
. All those information are underSdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
ofSdkHttpOperation
. So we need to mapSdkMethodParameter
toSdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
to get more information to generate convenient method.One thing I found inconvenient is current TCGC only contains mapping from
SdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
toSdkMethodParameter
, I wonder if TCGC could provide a helper function or properties onSdkMethodParameter
to let emitter mapSdkMethodParameter
toSdkPathParameter | SdkQueryParameter | SdkHeaderParameter | SdkBodyParameter
?@iscai-msft , @tadelesh , what do you think?