ToResponse response derive should be possible to namespace

[d-hain]

I am currently writing a very simple application using rocket and there I am using the Responder derive macro to make my enum response types.
Like this:

#[derive(Responder)]
enum AddResponse {
    #[response(status = 201, content_type = "json")]
    Created { url: String },
}

And this works perfectly fine.
But as soon as I want to put these enums in my uitopa OpenAPI docs I get a problem.
To do it I need to annotate my enums with the ToResponse derive macro. But that one also has a response derive available inside the enum.
So if I change my above example to this:

#[derive(Responder, ToResponse)]
enum AddResponse {
    #[response(status = 201, content_type = "json")]
    Created { url: String },
}

I get this error:

error: unexpected attribute: status, expected any of: inline, description, content_type, headers, example
  --> src/main.rs:26:16
   |
26 |     #[response(status = 201, content_type = "json")]
   |                ^^^^^^

So my proposal would be to be able to do something like this:

#[derive(Responder, ToResponse)]
enum AddResponse {
    #[response(status = 201, content_type = "json")]
    #[utoipa_response(description = "Beautiful description")]
    Created { url: String },
}

Because AFAIK namespacing it like this utoipa::response does not work.
Sadly I cannot really do it myself as I have no experience with any kind of Rust macros.
Maybe this is also something that rocket should change.

[juhaku]

Oh snap. This would need utoipa or rocket to change the response attribute to something else. This is really unfortunate name clash between rocket and the utoipa where both frameworks expect different things to be found under the response attribute.

I am not fond of changing the attribute name to something like utoipa_response as it is quite verbose and long to type. Also let's say that I would change the attribute to something else then the ToSchema trait schema attribute should also be changed in similar fashion to be consistent througout the library. Probably the ToResponse thing could be re-evaluated sometime in future but it is not going to be a priority for now. There are probably some ways to make this more permissive for "unknown" attributes (attributes that are not part of the utoipa library) but that would need some architectural changes to work.

Some things to consider:

• Allow unknown attributes similar way the serde attributes are now being parsed.
• Allow unknown attributes per trait basis with certain known external attributes that can be ingored.

Perhaps now there are no good way around the issue e.g. If new type pattern cannot be leveraged correctly then I guess the only option for now is to not to use the ToResponse trait. :/

[d-hain]

Ok that is very unfortunate.
So would it be possible to put my responses in my docs in any way or not?

[juhaku]

One way is to use the tuples to define responses with the utoipa::path macro manually. Perhaps sometime in future it might be useful to consider supporting the rocket Responder attributes directly if there is enough demand for that.

[d-hain]

Ok thank you, I'll do that as long as deriving Responder and ToResponse is not possible 👍