Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Precisions related to the httpResponseCode trait #2135

Closed
Baccata opened this issue Feb 9, 2024 · 3 comments · Fixed by #2308
Closed

Precisions related to the httpResponseCode trait #2135

Baccata opened this issue Feb 9, 2024 · 3 comments · Fixed by #2308

Comments

@Baccata
Copy link

Baccata commented Feb 9, 2024

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, is 400 considered valid dynamic value for the code member of FooOutput ?
  • When a call to the Foo operation fails with ClientError, are 200 and 500 considered valid dynamic values for the code member of ClientError ?
  • When a call to the Foo operation fails with ServerError, are 200 and 400 considered valid dynamic values for the code member of ServerError?
@mtdowling
Copy link
Member

mtdowling commented Feb 9, 2024

@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.

@daddykotex
Copy link
Contributor

daddykotex commented Feb 9, 2024

Thanks, for your answer.

Still, could an implementation return new FooOutput(404) ?

@mtdowling
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants