Many common possible HTTP status codes are not represented in the explicitly named response enum variants #41
Comments
Arnavion
pushed a commit
that referenced
this issue
Apr 22, 2019
…associated type. The spec does not record any possible HTTP status codes other than HTTP 200, 201, 202 and 401. But in common operation, many APIs can fail with HTTP 403, GETs on non-existent resources can fail with HTTP 404, and PUTs on resources with the wrong resource version can fail with HTTP 409. This commit ignores all variants that don't have an associated type in the spec. This commit also changes the `Other` variant to have a `Result<Option<serde_json::Value>, serde_json::Error>` value. This allows the variant to handle the common case where the response contains a JSON value, but still allow the case of non-JSON content that the user should parse from the response body manually. Fixes #40 Fixes #41
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The spec does not record any possible HTTP status codes other than 200, 201, 202 and 401. But in common operation, many APIs can fail with HTTP 403, GETs on non-existent resources can fail with 404, and PUTs on resources with wrong resource version can fail with 409.
It may be worth not pretending to have named variants like
Unauthorizedwhen users will have to commonly handle theOthervariant as well. So for variants that have no data, it may be worth not emitting them at all, and letting theOthervariant match them.The text was updated successfully, but these errors were encountered: