- What is grape-swagger?
- Related Projects
- Compatibility
- Swagger-Spec
- Installation
- Usage
- Model Parsers
- Configure
- Routes Configuration
- Markdown
- Response documentation
- Extensions
- Example
The grape-swagger gem provides an autogenerated documentation for your Grape API. The generated documentation is Swagger-compliant, meaning it can easily be discovered in Swagger UI. You should be able to point the petstore demo to your API.
These screenshot is based on the Hussars sample app.
## Related Projects ## CompatibilityThe following versions of grape, grape-entity and grape-swagger can currently be used together.
grape-swagger | swagger spec | grape | grape-entity | representable |
---|---|---|---|---|
0.10.5 | 1.2 | >= 0.10.0 ... <= 0.14.0 | < 0.5.0 | n/a |
0.11.0 | 1.2 | >= 0.16.2 | < 0.5.0 | n/a |
0.20.1 | 2.0 | >= 0.12.0 ... <= 0.14.0 | <= 0.5.1 | n/a |
0.20.3 | 2.0 | >= 0.12.0 ... ~> 0.16.2 | ~> 0.5.1 | n/a |
0.21.0 | 2.0 | >= 0.12.0 ... <= 0.16.2 | <= 0.5.1 | >= 2.4.1 |
0.21.1 (next) | 2.0 | >= 0.12.0 ... <= 0.16.2 | <= 0.5.1 | >= 2.4.1 |
Grape-swagger generates documentation per Swagger / OpenAPI Spec 2.0.
## InstallationAdd to your Gemfile:
gem 'grape-swagger'
Please see UPGRADING when upgrading from a previous version.
## UsageMount all your different APIs (with Grape::API
superclass) on a root node. In the root class definition, include add_swagger_documentation
, this sets up the system and registers the documentation on '/swagger_doc'. See example/config.ru for a simple demo.
require 'grape-swagger'
module API
class Root < Grape::API
format :json
mount API::Cats
mount API::Dogs
mount API::Pirates
add_swagger_documentation
end
end
To explore your API, either download Swagger UI and set it up yourself or go to the online swagger demo and enter your localhost url documentation root in the url field (probably something in the line of http://localhost:3000/swagger_doc).
## Model ParsersSince 0.21.0, Grape::Entity
is not a part of grape-swagger, you need to add grape-swagger-entity
manually to your Gemfile.
Also added support for representable via grape-swagger-representable
.
# For Grape::Entity ( https://github.com/ruby-grape/grape-entity )
gem 'grape-swagger-entity'
# For representable ( https://github.com/apotonick/representable )
gem 'grape-swagger-representable'
If you are not using Rails, make sure to load the parser inside your application initialization logic, e.g., via require 'grape-swagger/entity'
or require 'grape-swagger/representable
.
You can create your own model parser, for example for roar.
module GrapeSwagger
module Roar
class Parser
attr_reader :model
attr_reader :endpoint
def initialize(model, endpoint)
@model = model
@endpoint = endpoint
end
def call
# Parse your model and return hash with model schema for swagger
end
end
end
end
Then you should register your custom parser.
GrapeSwagger.model_parsers.register(GrapeSwagger::Roar::Parser, Roar::Decorator)
To control model parsers sequence, you can insert your parser before or after another parser.
GrapeSwagger.model_parsers.insert_before(GrapeSwagger::Representable::Parser, GrapeSwagger::Roar::Parser, Roar::Decorator)
GrapeSwagger.model_parsers.insert_after(GrapeSwagger::Roar::Parser, GrapeSwagger::Representable::Parser, Representable::Decorator)
As we know, Roar::Decorator
uses as superclass Representable::Decorator
, this allow to avoid problem when Roar objects will be processed by GrapeSwagger::Representable::Parser
, instead GrapeSwagger::Roar::Parser
.
If you use the online demo, make sure your API supports foreign requests by enabling CORS in Grape, otherwise you'll see the API description, but requests on the API won't return. Use rack-cors to enable CORS.
require 'rack/cors'
use Rack::Cors do
allow do
origins '*'
resource '*', headers: :any, methods: [ :get, :post, :put, :delete, :options ]
end
end
```
Alternatively you can set CORS headers in a Grape `before` block.
```ruby
before do
header['Access-Control-Allow-Origin'] = '*'
header['Access-Control-Request-Method'] = '*'
end
- host
- base_path
- mount_path
- add_base_path
- add_version
- doc_version
- markdown
- models
- hide_documentation_path
- info
You can pass a hash with optional configuration settings to add_swagger_documentation
.
not all configuration options supported yet, but is WIP
The host
and base_path
options also accept a proc
or lambda
to evaluate, which is passed a request object:
add_swagger_documentation \
base_path: proc { |request| request.host =~ /^example/ ? '/api-example' : '/api' }
host
and base_path
are also accepting a proc
or lambda
Add basePath
key to the documented path keys, default is: false
.
add_swagger_documentation \
add_base_path: true
Add version
key to the documented path keys, default is: true
,
here the version is the API version, specified by grape
in path
add_swagger_documentation \
add_version: false
add_swagger_documentation \
markdown: GrapeSwagger::Markdown::KramdownAdapter.new
or alternative
add_swagger_documentation \
markdown: GrapeSwagger::Markdown::RedcarpetAdapter.new
This value is added to the authorizations
key in the JSON documentation.
These would be added to the definitions section of the swagger file.
add_swagger_documentation \
models: [
TheApi::Entities::UseResponse,
TheApi::Entities::ApiError
]
Don't show the /swagger_doc
path in the generated swagger documentation.
A hash merged into the info
key of the JSON documentation.
- Swagger Header Parameters
- Hiding an Endpoint
- Overriding Auto-Generated Nicknames
- Defining an endpoint as array
- Using an options hash
- Specify endpoint details
- Overriding param type
- Overriding type
- Multi types
- Response documentation
Swagger also supports the documentation of parameters passed in the header. Since grape's params[]
doesn't return header parameters we can specify header parameters seperately in a block after the description.
desc "Return super-secret information", {
headers: {
"XAuthToken" => {
description: "Valdates your identity",
required: true
},
"XOptionalHeader" => {
description: "Not really needed",
required: false
}
}
}
You can hide an endpoint by adding hidden: true
in the description of the endpoint:
desc 'Hide this endpoint', hidden: true
Endpoints can be conditionally hidden by providing a callable object such as a lambda which evaluates to the desired state:
desc 'Conditionally hide this endpoint', hidden: lambda { ENV['EXPERIMENTAL'] != 'true' }
You can specify a swagger nickname to use instead of the auto generated name by adding `:nickname 'string'``` in the description of the endpoint.
desc 'Get a full list of pets', nickname: 'getAllPets'
You can define an endpoint as array by adding is_array
in the description:
desc 'Get a full list of pets', is_array: true
The Grape DSL supports either an options hash or a restricted block to pass settings. Passing the nickname
, hidden
and is_array
options together with response codes is only possible when passing an options hash.
Since the syntax differs you'll need to adjust it accordingly:
desc 'Get all kittens!', {
hidden: true,
is_array: true,
nickname: 'getKittens',
entity: Entities::Kitten, # or success
http_codes: [[401, 'KittenBitesError', Entities::BadKitten]] # or failure
# also explicit as hash: [{ code: 401, mssage: 'KittenBitesError', model: Entities::BadKitten }]
produces: [ "array", "of", "mime_types" ],
consumes: [ "array", "of", "mime_types" ]
}
get '/kittens' do
To specify further details for an endpoint, use the detail
option within a block passed to desc
:
desc 'Get all kittens!' do
detail 'this will expose all the kittens'
end
get '/kittens' do
You can override paramType in POST|PUT methods to query, using the documentation hash.
params do
requires :action, type: Symbol, values: [:PAUSE, :RESUME, :STOP], documentation: { param_type: 'query' }
end
post :act do
...
end
You can override type, using the documentation hash.
params do
requires :input, type: String, documentation: { type: 'integer' }
end
post :act do
...
end
{
"in": "formData",
"name": "input",
"type": "integer",
"format": "int32",
"required": true
}
By default when you set multi types, the first type is selected as swagger type
params do
requires :action, types: [String, Integer]
end
post :act do
...
end
{
"in": "formData",
"name": "action",
"type": "string",
"required": true
}
By default, the route summary is filled with the value supplied to desc
.
namespace 'order' do
desc 'This will be your summary'
get :order_id do
...
end
end
To override the summary, add summary: '[string]'
after the description.
namespace 'order' do
desc 'This will be your summary',
summary: 'Now this is your summary!'
get :order_id do
...
end
end
Use the nested: false
property in the swagger
option to make nested namespaces appear as standalone resources.
This option can help to structure and keep the swagger schema simple.
namespace 'store/order', desc: 'Order operations within a store', swagger: { nested: false } do
get :order_id do
...
end
end
All routes that belong to this namespace (here: the GET /order_id
) will then be assigned to the store_order
route instead of the store
resource route.
It is also possible to expose a namespace within another already exposed namespace:
namespace 'store/order', desc: 'Order operations within a store', swagger: { nested: false } do
get :order_id do
...
end
namespace 'actions', desc: 'Order actions' do, nested: false
get 'evaluate' do
...
end
end
end
Here, the GET /order_id
appears as operation of the store_order
resource and the GET /evaluate
as operation of the store_orders_actions
route.
Auto generated names for the standalone version of complex nested resource do not have a nice look.
You can set a custom name with the name
property inside the swagger
option, but only if the namespace gets exposed as standalone route.
The name should not contain whitespaces or any other special characters due to further issues within swagger-ui.
namespace 'store/order', desc: 'Order operations within a store', swagger: { nested: false, name: 'Store-orders' } do
get :order_id do
...
end
end
Grape allows for an additional documentation hash to be passed to a parameter.
params do
requires :id, type: Integer, desc: 'Coffee ID'
requires :temperature, type: Integer, desc: 'Temperature of the coffee in celcius', documentation: { default: 72 }
end
The example parameter will populate the Swagger UI with the example value, and can be used for optional or required parameters.
Grape uses the option default
to set a default value for optional parameters. This is different in that Grape will set your parameter to the provided default if the parameter is omitted, whereas the example value above will only set the value in the UI itself. This will set the Swagger defaultValue
to the provided value. Note that the example value will override the Grape default value.
params do
requires :id, type: Integer, desc: 'Coffee ID'
optional :temperature, type: Integer, desc: 'Temperature of the coffee in celcius', default: 72
end
Add the grape-entity gem to your Gemfile.
The following example exposes statuses. And exposes statuses documentation adding :type and :desc.
module API
module Entities
class Status < Grape::Entity
expose :text, documentation: { type: 'string', desc: 'Status update text.' }
expose :links, using: Link, documentation: { type: 'link', is_array: true }
expose :numbers, documentation: { type: 'integer', desc: 'favourite number', values: [1,2,3,4] }
end
class Link < Grape::Entity
expose :href, documentation: { type: 'url' }
expose :rel, documentation: { type: 'string'}
end
end
class Statuses < Grape::API
version 'v1'
desc 'Statuses index',
entity: API::Entities::Status
get '/statuses' do
statuses = Status.all
type = current_user.admin? ? :full : :default
present statuses, with: API::Entities::Status, type: type
end
desc 'Creates a new status',
entity: API::Entities::Status,
params: API::Entities::Status.documentation
post '/statuses' do
...
end
end
end
You may safely omit type
from relationships, as it can be inferred. However, if you need to specify or override it, use the full name of the class leaving out any modules named Entities
or Entity
.
module API
module Entities
class Client < Grape::Entity
expose :name, documentation: { type: 'string', desc: 'Name' }
expose :addresses, using: Entities::Address,
documentation: { type: 'API::Address', desc: 'Addresses.', param_type: 'body', is_array: true }
end
class Address < Grape::Entity
expose :street, documentation: { type: 'string', desc: 'Street.' }
end
end
class Clients < Grape::API
version 'v1'
desc 'Clients index', params: Entities::Client.documentation
get '/clients' do
...
end
end
add_swagger_documentation models: [Entities::Client, Entities::Address]
end
Note: is_array
is false
by default.
module API
module Entities
class Client < Grape::Entity
expose :name, documentation: { type: 'string', desc: 'Name' }
expose :address, using: Entities::Address,
documentation: { type: 'API::Address', desc: 'Addresses.', param_type: 'body', is_array: false }
end
class Address < Grape::Entity
expose :street, documentation: { type: 'string', desc: 'Street' }
end
end
class Clients < Grape::API
version 'v1'
desc 'Clients index', params: Entities::Client.documentation
get '/clients' do
...
end
end
add_swagger_documentation models: [Entities::Client, Entities::Address]
end
The grape-swagger gem allows you to add an explanation in markdown in the detail field. Which would result in proper formatted markdown in Swagger UI. Grape-swagger uses adapters for several markdown formatters. It includes adapters for kramdown (kramdown syntax) and redcarpet. The adapters are packed in the GrapeSwagger::Markdown modules. We do not include the markdown gems in our gemfile, so be sure to include or install the depended gems.
To use it, add a new instance of the adapter to the markdown options of add_swagger_documentation
, such as:
add_swagger_documentation \
markdown: GrapeSwagger::Markdown::KramdownAdapter.new(options)
and write your route details in GFM, examples could be find in details spec
If you want to use kramdown as markdown formatter, you need to add kramdown to your gemfile.
gem 'kramdown'
Configure your api documentation route with:
add_swagger_documentation \
markdown: GrapeSwagger::Markdown::KramdownAdapter.new(options)
As alternative you can use redcarpet as formatter, you need to include redcarpet in your gemspec. If you also want to use rouge as syntax highlighter you also need to include it.
gem 'redcarpet'
gem 'rouge'
Configure your api documentation route with:
add_swagger_documentation(
markdown: GrapeSwagger::Markdown::RedcarpetAdapter.new(render_options: { highlighter: :rouge })
)
Alternatively you can disable rouge by adding :none
as highlighter option. You can add redcarpet extensions and render options trough the extenstions:
and render_options:
parameters.
You can also add your custom adapter for your favourite markdown formatter, as long it responds to the method markdown(text)
and it formats the given text.
module API
class FancyAdapter
attr_reader :adapter
def initialize(options)
require 'superbmarkdownformatter'
@adapter = SuperbMarkdownFormatter.new options
end
def markdown(text)
@adapter.render_supreme(text)
end
end
add_swagger_documentation markdown: FancyAdapter.new(no_links: true)
end
You can also document the HTTP status codes with a description and a specified model, as ref in the schema to the definitions, that your API returns with one of the following syntax.
In the following cases, the schema ref would be taken from route.
desc 'thing', http_codes: [ { code: 400, message: "Invalid parameter entry" } ]
get '/thing' do
...
end
desc 'thing' do
params Entities::Something.documentation
http_codes [ { code: 400, message: "Invalid parameter entry" } ]
end
get '/thing' do
...
end
get '/thing', http_codes: [
{ code: 200, message: 'Ok' },
{ code: 400, message: "Invalid parameter entry" }
] do
...
end
By adding a model
key, e.g. this would be taken.
get '/thing', http_codes: [
{ code: 200, message: 'Ok' },
{ code: 422, message: "Invalid parameter entry", model: Entities::ApiError }
] do
...
end
If no status code is defined defaults would be taken.
The result is then something like following:
"responses": {
"200": {
"description": "get Horses",
"schema": {
"$ref": "#/definitions/Thing"
}
},
"401": {
"description": "HorsesOutError",
"schema": {
"$ref": "#/definitions/ApiError"
}
}
},
Swagger spec2.0 supports extensions on different levels, for the moment,
the documentation on verb
, path
and definition
level would be supported.
The documented key would be generated from the x
+ -
+ key of the submitted hash,
for possibilities refer to the extensions spec.
To get an overview how the extensions would be defined on grape level, see the following examples:
verb
extension, add ax
key to thedesc
hash:
desc 'This returns something with extension on verb level',
x: { some: 'stuff' }
this would generate:
"/path":{
"get":{
"…":"…",
"x-some":"stuff"
}
}
path
extension, by setting via route settings:
route_setting :x_path, { some: 'stuff' }
this would generate:
"/path":{
"x-some":"stuff",
"get":{
"…":"…",
}
}
definition
extension, again by setting via route settings, here the status code must be provided, for which definition the extensions should be:
route_setting :x_def, { for: 422, other: 'stuff' }
this would generate:
"/definitions":{
"ApiError":{
"x-other":"stuff",
"…":"…",
}
}
or, for more definitions:
route_setting :x_def, [{ for: 422, other: 'stuff' }, { for: 200, some: 'stuff' }]
<a="example" />
Go into example directory and run it: $ bundle exec rackup
go to: http://localhost:9292/swagger_doc
to get it
For request examples load the postman file
Use namespace for grouping APIs
class NamespaceApi < Grape::API
namespace :hudson do
desc 'Document root'
get '/' do
end
end
namespace :hudson do
desc 'This gets something.',
notes: '_test_'
get '/simple' do
{ bla: 'something' }
end
end
namespace :colorado do
desc 'This gets something for URL using - separator.',
notes: '_test_'
get '/simple-test' do
{ bla: 'something' }
end
end
end
…
See CONTRIBUTING.
Copyright (c) 2012-2014 Tim Vandecasteele and contributors. See LICENSE.txt for details.