• What is grape-swagger?
• Related Projects
• Compatibility
• Swagger-Spec
• Installation
• Usage
• Model Parsers
• Configure
• Routes Configuration
• Securing the Swagger UI
• Markdown
• Response documentation
• Extensions
• Example
• Rake Tasks

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.

• Grape
• Grape Swagger Entity
  • Grape Entity
• Grape Swagger Representable
• Swagger UI

Grape-swagger generates documentation per Swagger / OpenAPI Spec 2.0.

gem 'grape-swagger'

Please see UPGRADING when upgrading from a previous version.

Mount 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).

Since 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
• endpoint_auth_wrapper
• swagger_endpoint_guard
• oauth_token
• security_definitions
• models
• hide_documentation_path
• info

You can pass a hash with optional configuration settings to add_swagger_documentation. The examples shows the default value.

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' }

Add basePath key to the documented path keys, default is: false.

add_swagger_documentation \ add_base_path: true # only if base_path given

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: true

add_swagger_documentation \ markdown: GrapeSwagger::Markdown::KramdownAdapter.new

add_swagger_documentation \ markdown: GrapeSwagger::Markdown::RedcarpetAdapter.new

add_swagger_documentation \ endpoint_auth_wrapper: WineBouncer::OAuth2

add_swagger_documentation \ swagger_endpoint_guard: 'oauth2 false'

add_swagger_documentation \ oauth_token: 'doorkeeper_access_token'

add_swagger_documentation \ security_definitions: { api_key: { type: "apiKey", name: "api_key", in: "header" } }

add_swagger_documentation \ models: [ TheApi::Entities::UseResponse, TheApi::Entities::ApiError ]

• 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
• Hiding parameters
• Response documentation

desc "Return super-secret information", { headers: { "XAuthToken" => { description: "Valdates your identity", required: true }, "XOptionalHeader" => { description: "Not really needed", required: false } } }

desc 'Hide this endpoint', hidden: true

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'

desc 'Get a full list of pets', is_array: true

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

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 }

Array types are also supported.

params do requires :action_ids, type: Array[Integer] end post :act do ... end

{ "in": "formData", "name": "action_ids", "type": "array", "items": { "type": "integer" }, "required": true }

You can set the collection format of an array, using the documentation hash.

Collection format determines the format of the array if type array is used. Possible values are:

• csv - comma separated values foo,bar.
• ssv - space separated values foo bar.
• tsv - tab separated values foo\tbar.
• pipes - pipe separated values foo|bar.
• multi - corresponds to multiple parameter instances instead of multiple values for a single instance foo=bar&foo=baz. This is valid only for parameters in "query" or "formData".

params do requires :statuses, type: Array[String], documentation: { collectionFormat: 'multi' } end post :act do ... end

{ "in": "formData", "name": "statuses", "type": "array", "items": { "type": "string" }, "collectionFormat": "multi", "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 }

Exclude single optional parameter from the documentation

params do optional :one, documentation: { hidden: true } optional :two, documentation: { hidden: -> { true } } end post :act do ... end

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

• Markdown in Detail
• Response documentation

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 WineBouncer and Doorkeeper gems are used in the examples;
• 'rails' and 'wine_bouncer' gems should be required prior to 'grape-swagger' in boot.rb;
• This works with a fresh PR to WineBouncer which is yet unmerged - WineBouncer PR.

This is how to configure the grape_swagger documentation:

 add_swagger_documentation base_path: '/', title: 'My API', doc_version: '0.0.1', hide_documentation_path: true, hide_format: true, endpoint_auth_wrapper: WineBouncer::OAuth2, # This is the middleware for securing the Swagger UI swagger_endpoint_guard: 'oauth2 false', # this is the guard method and scope oauth_token: 'doorkeeper_access_token' # This is the method returning the access_token

The guard method should inject the Security Requirement Object into the endpoint's route settings (see Grape::DSL::Settings.route_setting method).

The 'oauth2 false' added to swagger_documentation is making the main Swagger endpoint protected with OAuth, i.e. it is retreiving the access_token from the HTTP request, but the 'false' scope is for skipping authorization and showing the UI for everyone. If the scope would be set to something else, like 'oauth2 admin', for example, than the UI wouldn't be displayed at all to unauthorized users.

Further on, the guard could be used, where necessary, for endpoint access protection. Put it prior to the endpoint's method:

 resource :users do oauth2 'read, write' get do render_users end oauth2 'admin' post do User.create!... end end

And, finally, if you want to not only restrict the access, but to completely hide the endpoint from unauthorized users, you could pass a lambda to the :hidden key of a endpoint's description:

 not_admins = lambda { |token=nil| token.nil? || !User.find(token.resource_owner_id).admin? } resource :users do desc 'Create user', hidden: not_admins oauth2 'admin' post do User.create!... end end

The lambda is checking whether the user is authenticated (if not, the token is nil by default), and has the admin role - only admins can see this endpoint.

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

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

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 a x key to the desc 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 …

require 'grape-swagger/rake/oapi_tasks' GrapeSwagger::Rake::OapiTasks.new(::Api::Base)

rake oapi:fetch params: - store={ true | file_name } – save as JSON (optional) - resource=resource_name – get only for this one (optional) 

requires: npm and swagger-cli to be installed

rake oapi:validate params: - resource=resource_name – get only for this one (optional) 

See CONTRIBUTING.

Copyright (c) 2012-2014 Tim Vandecasteele and contributors. See LICENSE.txt for details.