How to deserialize optional `@httpPayload`-bound shapes?

I already raised this to some extent in:

The problem is how to deserialize something like:

structure OperationBoundInput {
    @httpPayload
    message: String
}

It is unclear, if the user doesn't provide a value for message in the HTTP body, whether a server should deserialize message as None or as "".

Note that the HTTP RFC differentiates between HTTP messages with no body (no Content-Length or Transfer-Encoding header) and HTTP messages with an empty body (Content-Length: 0). This is only the case for requests.

For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1)

So we could use that distinction to deserialize one way or another, but I think the UX would be confusing and the implementation prone to bugs.

A much simpler possibility is if we enforced @httpPayload to be coupled with @required or @default when the target of the member shape is a simple shape type. This would be in accordance with the decision that was taken in IDL v2 for @streaming blob shapes.

If the target member shape is an aggregate type, protocols' serialization formats should have "enclosing tokens" to delimit the aggregate data (e.g. {} in JSON), so we could ascribe the absence of those markers to deserialization as None.

smithy-lang / smithy

How to deserialize optional `@httpPayload`-bound shapes? #2311