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.

Add to your Gemfile:

gem 'grape-swagger'

Upgrade

Please see UPGRADING when upgrading from a previous version.

## Usage

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

## Model Parsers

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.

Custom Model Parsers

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.

insert_before

GrapeSwagger.model_parsers.insert_before(GrapeSwagger::Representable::Parser, GrapeSwagger::Roar::Parser, Roar::Decorator)

insert_after

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.

CORS

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

## Configure

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: Sets explicit the `host`, default would be taken from `request`. ```ruby add_swagger_documentation \ host: 'www.example.com' ``` #### base_path: Base path of the API that's being exposed, default would be taken from `request`. ```ruby add_swagger_documentation \ base_path: '/super/api' ```

host and base_path are also accepting a proc or lambda

#### mount_path: The path where the API documentation is loaded, default is: `/swagger_doc`. ```ruby add_swagger_documentation \ mount_path: '/docu' ```

add_base_path:

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

add_swagger_documentation \
   add_base_path: true

add_version:

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

#### doc_version: Specify the version of the documentation at [info section](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#info-object), default is: `'0.0.1'` ```ruby add_swagger_documentation \ doc_version: '0.0.1' ``` #### markdown: Allow markdown in `detail`, default is `false`. (disabled) See [below](#md_usage) for details.

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

or alternative

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

authorizations:

This value is added to the authorizations key in the JSON documentation.

#### models: A list of entities to document. Combine with the [grape-entity](https://github.com/ruby-grape/grape-entity) gem.

These would be added to the definitions section of the swagger file.

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

#### hide_documentation_path: (default: `true`) ```ruby add_swagger_documentation \ hide_documentation_path: true ```

Don't show the /swagger_doc path in the generated swagger documentation.

#### info: ```ruby add_swagger_documentation \ info: { title: "The API title to be displayed on the API homepage.", description: "A description of the API.", contact_name: "Contact name", contact_email: "Contact@email.com", contact_url: "Contact URL", license: "The name of the license.", license_url: "www.The-URL-of-the-license.org", terms_of_service_url: "www.The-URL-of-the-terms-and-service.com", } ```

A hash merged into the info key of the JSON documentation.

## Routes Configuration

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 Header Parameters

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

#### Hiding an Endpoint

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

Overriding Auto-Generated Nicknames

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'

#### Defining an endpoint as array

You can define an endpoint as array by adding is_array in the description:

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

#### Using an options hash

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

#### Specify endpoint details

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

Overriding param type

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

Overriding type

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
}

Multi types

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
}

Overriding the route summary

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

Expose nested namespace as standalone route

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.

With a custom name

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

## Additional documentation

Markdown in Detail
Response documentation

Setting a Swagger defaultValue

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

Grape Entities

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

Relationships

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.

1xN

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

1x1

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

### Markdown in Detail

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

Kramdown

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)

Redcarpet

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.

Custom markdown formatter

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

## Response documentation

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"
    }
  }
},

## Extensions

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" />

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

Grouping the API list using Namespace

Use namespace for grouping APIs

Example

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
  …

Contributing to grape-swagger

See CONTRIBUTING.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.md

README.md

Table of Contents

Upgrade

Custom Model Parsers

insert_before

insert_after

CORS

add_base_path:

add_version:

authorizations:

Overriding Auto-Generated Nicknames

Overriding param type

Overriding type

Multi types

Overriding the route summary

Expose nested namespace as standalone route

With a custom name

Setting a Swagger defaultValue

Grape Entities

Relationships

1xN

1x1

Kramdown

Redcarpet

Custom markdown formatter

Example

Grouping the API list using Namespace

Example

Contributing to grape-swagger

Copyright and License

Files

README.md

Latest commit

History

README.md

File metadata and controls

Table of Contents

Upgrade

Custom Model Parsers

insert_before

insert_after

CORS

add_base_path:

add_version:

authorizations:

Overriding Auto-Generated Nicknames

Overriding param type

Overriding type

Multi types

Overriding the route summary

Expose nested namespace as standalone route

With a custom name

Setting a Swagger defaultValue

Grape Entities

Relationships

1xN

1x1

Kramdown

Redcarpet

Custom markdown formatter

Example

Grouping the API list using Namespace

Example

Contributing to grape-swagger

Copyright and License