Relax httpPayload constraints

[Baccata]

Using smithy-model 1.3.0 :

The problem:

The httpPayload trait is currently constrained to target a member that itself points to :

• a structure
• a blob
• a string
• a union
• a document

I'm trying to translate a couple of my organisation's APIs to smithy semantics, to assess whether it'd work for us as an IDL. We have several endpoints (think rest-json) that return maps/lists in the body of the responses, which is currently not possible to describe in smithy (using out-of-the-box features) due to the constraints on the httpPayload trait.

And educated guess tells me that the constraints on the httpPayload trait come from the xml-based protocols which AWS uses. Imho, these constraints should not be inherent to the trait, but rather tied to protocol-specific validation logic.

Obvious, I'd prefer not having to define my own http-bindings set of traits, as piggybacking on the ones provided out of the box drastically lowers the effort required for building tooling.

My questions :

• Would AWS consider relaxing the constraints on the httpPayload trait ?
• Is there a current workaround I could use short-term that would let me override the constraints, either via pure-smithy semantics, or via a service-provider ? (NB : I'm using a different build-tool than Gradle and the smithy-build.json semantics are of no use to me, currently anyway)

PS : I'm greatly enjoying prototyping tooling around smithy, keep up the good work 😄

[mtdowling]

Thanks for raising this issue. I think we'd be open to expanding the httpPayload trait to support lists, maps, and sets. We'll do more research to see what the estimated effort for this would be in AWS SDKs and our internal frameworks.

[JordonPhillips]

The more I think about this the more I think we should do it. OpenAPI does seem to allow it, and technically a Document shape could be any json-like data so it kind of already is allowed. I still need to do some research to see if it breaks any AWS tooling (and if so, how we mitigate that) but one way or another I think it should be done.

[ghost]

Are there any plans to update the HTTP spec documentation and add tests to the rest-json-1 protocol test suite to exercise this new functionality?

[kstich]

As the documentation introduced in #683 indicates, the AWS protocols do not support this behavior at this time.

[JordonPhillips]

We'll do new documentation build once this goes out in a release

[ghost]

Thank you.