not yet implemented: media type encoding, no schema: MediaType

[Kranzes]

When trying to generate a client from the following json I get the error.

thread 'main' panicked at /home/kranzes/.cargo/registry/src/index.crates.io-6f17d22bba15001f/progenitor-impl-0.6.0/src/method.rs:508:25:
not yet implemented: media type encoding, no schema: MediaType {
    schema: None,
    example: None,
    examples: {},
    encoding: {},
    extensions: {},
}

[ahl]

There are quite a few responses of this form:

        "responses": {
          "200": {
            "content": {
              "application/json;charset=utf-8": {}
            },
            "description": ""
          },

I'm not entirely sure what to make of these. According to a claim in the OpenAPI repo (that seems to conflict with the actual spec and the topic of binary responses), it's permissible to have an empty or absent schema for a non-JSON content type... but this content type is JSON. I'm not sure if the intention of this spec is that the response will be empty or that the response could be ... anything!

Do you happen to know the actual response and/or the intention of the folks who publish this OpenAPI document?

[Kranzes]

cc. @roberth

[roberth]

They're generated by servant-openapi3 for responses that return NoContent. I believe the response for it is typically success responses for actions like deleting a resource or uploading a file.
I believe the returned JSON is [] or {}, representing Haskell's (or Rust's) ().
However, the schema isn't specific enough, so I would not recommend to generate code returning ().

I think it'd be fine for a client to return the non-validated JSON in cases like this.
I'll consider adding more useful return values, but this problem seems likely to reoccur with other Haskell Servant based APIs.

[ahl]

It's surprising that a 204 response would contain a content block. I see both 200 and 204 responses; it's surprising that a 200 would be used to indicate NoContent and would also have an empty content block. Perhaps we should treat an absent schema as we would schema: {} or schema: true such that the client would get a serde_json::Value response.

Would it be worth filing an issue with servant-openapi3 to change this behavior? If it's a 204 response, there should (I think) be no content structure. If it's a 200 response with content, there should be a schema... even if it's the permissive schema.