microsoft / microsoft/typespec
[hsjs] Fundamental content-type body handling
- Dominant language
- Java
- Stars
- 5.9k
- Forks
- 394
- Avg merge
- 1d 23h
- Merged PRs (30d)
- 104
Description
In current HSJS, request/response body serialization is a cascading series of switch/if cases based on the type of the object that represents the body in TypeScript, the type of the body in TypeSpec, and the content-type of the request. Each branch of this cascading chain has to be implemented for both requests and responses. This issue proposes an alternative design:
- Assign _fundamental_ body types to all possible media types, for example:
-`application/json` -> `JsonValue`
- `text/plain` -> `Readable`
- `application/octet-stream` -> `Readable`
- `application/jsonl` -> `Readable`
- `application/x-www-form-urlencoded` -> `Record`
- Everything else: `Readable` (treated as octet-stream, to allow for unknown binary content types like `image/png` etc.)
- Create an **encoding table** similar to what we do for scalar encodings today that declaratively describes if and how various TypeSpec type kinds can be encoded/decoded to/from fundamental body types.
After adding support for scalar encodings, the architecture of scalar encoders in HSJS makes it _much_ easier to add add support for new scalars, new scalar encodings, and new default encodings in different HTTP positions, and I'd like to replicate this declarative "encoder" architecture for request bodies in general so that the raw server emit logic follow a simple path to compute a decoding chain for any type based on the content-type's fundamental representation, not just for scalars.
Contributor guide
Assessment
This issue has not been assessed yet.