Precisions related to the `httpResponseCode` trait
Closed this issue · 3 comments
Could you provide precisions related to the values that should be valid at runtime, regarding httpResponseCode
trait, in the AWS protocols that support it ?
In particular, considering the following :
@http(method: "GET", uri: "/", code: 200)
operation Foo {
output := {
@httpResponseCode
code: Integer
}
errors: [ClientError, ServerError]
}
@error("client")
structure ClientError {
@httpResponseCode
code: Integer
}
@error("server")
structure ServerError {
@httpResponseCode
code: Integer
}
- When a call to the
Foo
operation is successful, is400
considered valid dynamic value for thecode
member of FooOutput ? - When a call to the
Foo
operation fails withClientError
, are200
and500
considered valid dynamic values for thecode
member ofClientError
? - When a call to the
Foo
operation fails withServerError
, are200
and400
considered valid dynamic values for thecode
member ofServerError
?
@httpResponseCode
doesn't work on errors and is ignored (link):
httpResponseCode is only considered when applied to top-level members of an operation's output structure. This trait has no meaning in any other context and is simply ignored.
We could make sure to emit a warning when found elsewhere.
Thanks, for your answer.
Still, could an implementation return new FooOutput(404)
?
It’s undefined right now, but we should define it. I think it should be 2xx only for httpResponseCode.
In practice, the clients I can remember looking at their implementations wouldn’t work with anything outside of 2xx.
Clients are also supposed to be able to handle unmodeled HTTP errors. Intermediaries outside your frameworks might throttle, return 503, etc. Typically with errors, there’s some kind of signal it’s an error (e.g, a special header or something like __type). In the case of intermediaries, you can’t really enforce that, so it becomes harder if not impossible to unambiguously know if it’s a successful response or a random error.