Module decode 

One decode policy, for both surfaces.

The two halves, and why they are separate functions

Decoding a tapes response is two decisions that used to live in two crates and disagree:

1. Bytes to a document. Is this a success? If not, the body is the error message and must survive. Is the body empty? A 204 is a real answer, not a decode failure. That is json.
2. Document to a caller’s type. That is typed, and this crate takes no view on what the type should be.

Keeping them separate is what lets a consumer that already holds a decoded document — one whose own client did the fetching — reach the same typed decode the transport-driven path uses, instead of a second one that rounds differently.

Why T is the caller’s choice

The right answer is genuinely per-operation:

• Rendering operations decode into models, so a client can lay fields out rather than print a document.
• Fidelity operations — export, raw turns — stay Value. A typed decode there silently truncates the archive an old client writes of a newer server’s data, and it fails at the response level, so one unmodelled field can blank a whole page.

Whichever a consumer picks, the rule for anything this crate ever types is that enums carry a fallback variant: an added variant must never error an old client.

Functions

json

Turn one response’s bytes into a JSON document.

json_typed

Both halves, for the common case.

typed

Decode a document into the type the caller asked for.