Clarifying questions on the restJson1 protocol spec

[ghost]

I have a couple clarifying questions on the restJson1 spec.

Question 1

The spec states that the default Content-Type of application/json should be used, and that if there is a @httpPayload member, then there must be a Content-Type header and provides a table of possible values. What's not clear to me is what the expected behavior is when there are no members, or when there is no input/output shape on the operation. From what I can see in the protocol tests, the content type is application/json in these cases, but is that actually correct? Does it make sense to have a Content-Type when there is no content?

Tests I'm referencing:

• EmptyInputAndEmptyOutput, IgnoreQueryParamsInResponse, HttpResponseCode - Each of these is setting Content-Type to application/json when there is no JSON payload.
• GreetingWithErrors - This one, at a glance, looks like it is JSON, but the greeting value is actually a HTTP header, so there is no payload? I think?
• HttpPayloadTraits - From my understanding of the spec, I think this test should have a Content-Type of application/octet-stream?

I think I might be misunderstanding something.

Question 2

For HTTP headers in restJson1, I'm trying to figure out how the @sparse trait on lists/sets plays into header values. I couldn't find it mentioned in the spec, and didn't see any protocol tests that exercise it.

So if I have something like this:

@sparse
list SparseList {
    member: String
}

structure ExampleInput {
    @httpHeader("X-Example")
    example: SparseList,
}

Is this supported? If so, how are the null values expected to be serialized?

Thanks!

[mtdowling]

Thanks for pointing out these issues! All the points from question 1 seem like they're issues in the protocol tests. I'm addressing those in this PR: #692

As for sparse lists in headers -- great question. It's currently undefined behavior, and I'm not really sure how we'd support sending a null header.