microsoft / microsoft/typespec

[hsjs] Fundamental content-type body handling

Open
#6,932 0 comments 0 reactions 0 assignees View on GitHub
emitter:service:js feature triaged:core
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.