Multipart explicit parts

[timotheeguerin]

resolve #3046 Playground

Add the following:

• @multipartBody decorator
• File type
• HttpPart<Type, Options> type

Had to do a decent amount of refactoring to be able to reuse the body parsing, this result in a much cleaner resolution of the body and other metadata properties across request, response and metadata.

The way it works now is instead of calling gatherMetadata that would just get the properties that are metadata but also ones with @body and @bodyRoot we now call a resolveHtpProperties, this does the same resolution in term of filtering properties but it also figure out what is the kind of property in the concept of http(header, query, body, etc.) this leaves the error resolution to this function for duplicate annotations.
What is nice is now we don't need to keep asking oh is this a query or a header or a body we can just check the kind of HttpProperty

also resolve #1311

[azure-sdk]

All changed packages have been documented.

• ✅ @typespec/http
• ✅ @typespec/openapi3
• ✅ @typespec/rest

Show changes

@typespec/rest - internal ✏️

@typespec/http - feature ✏️

Add new multipart handling. Using @multipartBody with HttpPart<Type, Options>. See [multipart docs] for more information https://typespec.io/docs/next/libraries/http/multipart,> ,> tsp,> op upload(@header contentType: "multipart/mixed", @multipartBody body: {,> name: HttpPart<string>;,> avatar: HttpPart<bytes>[];,> }): void;,>

@typespec/openapi3 - fix ✏️

Add support for new multipart constructs in http library

[azure-sdk]

You can try these changes at https://cadlplayground.z22.web.core.windows.net/prs/3342/

Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/prs/3342/

[markcowl]

@timotheeguerin What are our plans for moving support for this into typespec-autorest?

[timotheeguerin]

@timotheeguerin What are our plans for moving support for this into typespec-autorest?

Need to make a follow up PR, though autorest support will be much more limited

[markcowl]

A few questions. Also, is there an uptake PR for typespec-azure, and can we look at the impact on the azure-rest-api-specs repo before merging?

[timotheeguerin]

A few questions. Also, is there an uptake PR for typespec-azure, and can we look at the impact on the azure-rest-api-specs repo before merging?

I do not but this doesn't affect the existing implicit multipart (if it did it would be a bug)

typespec autorest PR Azure/typespec-azure#902