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

Unsuccessful API response variants should have serde_json::Value data #40

Closed
Arnavion opened this issue Mar 30, 2019 · 0 comments
Closed

Comments

@Arnavion
Copy link
Owner

Arnavion commented Mar 30, 2019

For example:

#[derive(Debug)]
pub enum CreateCustomResourceDefinitionResponse {
    Ok(crate::v1_14::apiextensions_apiserver::pkg::apis::apiextensions::v1beta1::CustomResourceDefinition),
    Created(crate::v1_14::apiextensions_apiserver::pkg::apis::apiextensions::v1beta1::CustomResourceDefinition),
    Accepted(crate::v1_14::apiextensions_apiserver::pkg::apis::apiextensions::v1beta1::CustomResourceDefinition),
    Unauthorized,
    Other,
}

However, the API server usually returns some JSON object in the response for the non-successful status codes. Currently this means users that want this value have to parse it from the response buffer, which in turn means clients have to expose the response buffer along side the parsed response type.

So it would be useful to type Unauthorized, etc as (serde_json::Value). Usually it's a Status, but that would require emitting other variants that aren't Status to be safe. In any case, a serde_json::Value can be redeserialized as a Status if the user wants that.

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant