How to deserialize optional @httpPayload
-bound shapes?
#2311
Labels
client
This issue involves the specification for client software.
protocol-test
New protocol tests are needed
server
This issue involves the specification for server software.
I already raised this to some extent in:
httpPayload
and empty input/outputs in RestJson1 protocol tests #1068.The problem is how to deserialize something like:
It is unclear, if the user doesn't provide a value for
message
in the HTTP body, whether a server should deserializemessage
asNone
or as""
.Note that the HTTP RFC differentiates between HTTP messages with no body (no
Content-Length
orTransfer-Encoding
header) and HTTP messages with an empty body (Content-Length: 0
). This is only the case for requests.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 asNone
.The text was updated successfully, but these errors were encountered: