How to specify a constant HTTP header value in a Smithy model?
See original GitHub issueI’d like to model an API operation that requires a specific header value to be provided; I’d prefer not to pass the complexity on to the API consumer.
In my mind this should go into the @http trait applied to the operation shape, but from the docs that’s not supported.
Is there an existing trait that would be an appropriate way to do this?
@http(method:"POST", uri: "/", headers: { "api-version": "v1" })
operation DescribeThing {
...
}
Issue Analytics
- State:
- Created 2 years ago
- Comments:30 (12 by maintainers)
Top Results From Across the Web
11. HTTP binding traits - Smithy 1.0
The httpHeader trait can be applied to structure members that target a boolean , number , string , or timestamp ; or a...
Read more >HttpChecksumProperty.Location (Smithy API 1.12.0)
Package software.amazon.smithy.model.traits ... Enum Constant, Description. HEADER. The checksum is sent in an HTTP Header. ... Converts a value to a Node ....
Read more >Introducing Smithy IDL 2.0 | AWS Developer Tools Blog
Smithy is Amazon's next-generation API modeling language, based on our ... are used to represent a fixed set of string and integer values....
Read more >http - Go Packages
AddHeaderValue returns a stack mutator that adds the header value pair to ... Returns a smithy *Response, or error if the request failed....
Read more >Retry-After - HTTP - MDN Web Docs
The Retry-After response HTTP header indicates how long the user agent should wait before making a follow-up request.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@mtdowling got it, thanks. I like the idea of supporting this at both levels. I’d suggest semantics of “if you specify the same header name on a service and an operation then the operation will take precedence”. I don’t like the idea of it being impossible to override the default service value for an operation, and I expect that folks won’t accidentally add the trait to an operation. Thoughts?
@glb, when I first started using Smithy I expected to do something like this:
As you can see, if the
consttrait were available in Smithy IDL, we would be able to have constant values anywhere we want not only in headers.