Open Billiam opened 8 years ago
+1 Just sharing our use case, we also did something similar to @Billiam. We ended up creating a wrapper method called register_api
to avoid repetition, add default parameters, headers, etc, and handle adding API Gateway extensions, OPTIONS operation for CORS, etc.
This method in turn calls several helper methods to generate blocks for default responses, security, etc. It ended up making this example possible, for instance:
register_api :get, '/emails',
access_token_required: true,
success: 200,
params: {
location_ids: {
type: :array,
collectionFormat: :csv,
required: true,
description: 'The locations for which you are gathering emails',
items: {
type: :string
}
},
start_date: {type: :string, required: false, description: 'Optionally filter emails by start date'},
end_date: {type: :string, required: false, description: 'Optionally filter emails by end date'}
}
A project I'm working on needed reusable, predefined responses that were used globally.
To accomplish this, we patched
Swagger::Blocks::OperationNode
in a rails initializer, and included a module with a few methods (error_response
,success_response(type)
, etc) which return dynamic response blocks.This allows for code like:
While this works, it seems like there may be a better way to go about it, and has some side effects related to rails class_caching in development.
Do you have thoughts on either extension (plugins, helpers?), or other ways of handling reusable responses?