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

Allow SwaggerResponse attribute at class level? #158

Open
vincentparrett opened this issue Jan 16, 2018 · 4 comments
Open

Allow SwaggerResponse attribute at class level? #158

vincentparrett opened this issue Jan 16, 2018 · 4 comments

Comments

@vincentparrett
Copy link
Contributor

vincentparrett commented Jan 16, 2018

Currently, the SwaggerResponse is only valid for methods. As I get deeper into instrumenting my modules with the Nancy.Swagger attributes, I'm finding some modules have common attributes on every method, for example :

[SwaggerResponse(HttpStatusCode.Forbidden, Model = typeof(ForbiddenModel))]

is on pretty much every method I have instrumented so far.

Would it make sense to allow the SwaggerResponse at the method level?

@jnallard
Copy link
Collaborator

Yeah, it would be helpful.

A function like this would allow it to work without changing the existing flow (or another extension method).

private IEnumerable<T> GetCustomAttributes<T>(MethodInfo handler) where T: Attribute
{
	var attributes = handler.GetCustomAttributes<T>();
	return attributes.Concat(handler.DeclaringType.GetTypeInfo().GetCustomAttributes<T>());
} 

You would just need to replace the current GetCustomAttributes in AnnotatedOperation.
And once you allowed the Attributes to be applied to classes, it should just work.
Might be good to allow Parameters, such as for constant headers, and Tags as well, (although Tags is a bit trickier).

Feel free to try and implement! Otherwise I'll get to it later.

@vincentparrett
Copy link
Contributor Author

It's a bit more complicated than that, as you probably want to deal with duplicates for a start.

@jnallard
Copy link
Collaborator

True. There might be a response that you want for the whole module, but a certain route might want to override it.

That could still be implemented using my code.
Since the method attributes would be first in the IEnumerable, you could just ignore any duplicate responses afterwards. But what counts as a duplicate response? Something with the same status code? We didn't have that limit before, so that might break things.

Maybe just another method attribute that says to skip the class attributes.

@vincentparrett
Copy link
Contributor Author

I think a duplicate response would be by status code and model.

I think we should keep it simple, if it's on the class it's on all methods, otherwise you have to use method attributes.

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

2 participants