GitHub - anjlab/grape-swagger: Add swagger compliant documentation to your grape API

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.23.0	2.0	>= 0.12.0 ... <= 0.17.0	<= 0.5.1	>= 2.4.1

## Swagger-Spec

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

## Installation

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 Representable::Decorator as a superclass, this allows to avoid a problem when Roar objects are processed by GrapeSwagger::Representable::Parser instead of 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
```


<a name="configure" />
## Configure

* [host](#host)
* [base_path](#base_path)
* [mount_path](#mount_path)
* [add_base_path](#add_base_path)
* [add_version](#add_version)
* [doc_version](#doc_version)
* [markdown](#markdown)
* [endpoint_auth_wrapper](#endpoint_auth_wrapper)
* [swagger_endpoint_guard](#swagger_endpoint_guard)
* [token_owner](#token_owner)
* [security_definitions](#security_definitions)
* [models](#models)
* [hide_documentation_path](#hide_documentation_path)
* [info](#info)


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


The `host` and `base_path` options also accept a `proc` or a `lambda` to evaluate, which is passed a [request](http://www.rubydoc.info/github/rack/rack/Rack/Request) object:

```ruby
add_swagger_documentation \
  base_path: proc { |request| request.host =~ /^example/ ? '/api-example' : '/api' }
```

<a name="host" />
#### host:
Sets explicit the `host`, default would be taken from `request`.
```ruby
add_swagger_documentation \
   host: 'www.example.com'
```

<a name="base_path" />
#### base_path:
Base path of the API that's being exposed, default would be taken from `request`.
```ruby
add_swagger_documentation \
   base_path: nil
```

`host` and `base_path` are also accepting a `proc` or `lambda`

<a name="mount_path" />
#### mount_path:
The path where the API documentation is loaded, default is: `/swagger_doc`.
```ruby
add_swagger_documentation \
   mount_path: '/swagger_doc'
```

#### add_base_path:
Add `basePath` key to the documented path keys, default is: `false`.
```ruby
add_swagger_documentation \
   add_base_path: true # only if base_path given
```

#### 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`](https://github.com/ruby-grape/grape/#path)

```ruby
add_swagger_documentation \
   add_version: true
```

<a name="doc_version" />
#### 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'
```

<a name="markdown" />
#### markdown:
Allow markdown in `detail`, default is `false`. (disabled) See [below](#md_usage) for details.

```ruby
add_swagger_documentation \
  markdown: GrapeSwagger::Markdown::KramdownAdapter.new
```
or alternative
```ruby
add_swagger_documentation \
  markdown: GrapeSwagger::Markdown::RedcarpetAdapter.new
```

<a name="endpoint_auth_wrapper" />
#### endpoint_auth_wrapper:
Specify the middleware to use for securing endpoints.

```ruby
add_swagger_documentation \
   endpoint_auth_wrapper: WineBouncer::OAuth2
```

<a name="swagger_endpoint_guard" />
#### swagger_endpoint_guard:
Specify the method and auth scopes, used by the middleware for securing endpoints.

```ruby
add_swagger_documentation \
   swagger_endpoint_guard: 'oauth2 false'
```

<a name="token_owner" />
#### token_owner:
Specify the token_owner method, provided by the middleware, which is typically named 'resource_owner'.

```ruby
add_swagger_documentation \
   token_owner: 'resource_owner'
```

<a name="security_definitions" />
#### security_definitions:
Specify the [Security Definitions Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#security-definitions-object)

_NOTE: [Swagger-UI is supporting only implicit flow yet](https://github.com/swagger-api/swagger-ui/issues/2406#issuecomment-248651879)_

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

<a name="models" />
#### 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.

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

<a name="hide_documentation_path" />
#### 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.

<a name="info" />
#### 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: "[email protected]",
    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.

<!-- #### *authorizations*:
This value is added to the `authorizations` key in the JSON documentation. -->

<!-- #### *api_documentation*:
Customize the Swagger API documentation route, typically contains a `desc` field. The default description is "Swagger compatible API description".

```ruby
add_swagger_documentation \
   api_documentation: { desc: 'Reticulated splines API swagger-compatible documentation.' }
```


#### *specific_api_documentation*:
Customize the Swagger API specific documentation route, typically contains a `desc` field. The default description is "Swagger compatible API description for specific API".

```ruby
add_swagger_documentation \
   specific_api_documentation: { desc: 'Reticulated splines API swagger-compatible endpoint documentation.' }
``` -->


<a name="routes" />
## Routes Configuration

* [Swagger Header Parameters](#headers)
* [Hiding an Endpoint](#hiding)
* [Overriding Auto-Generated Nicknames](#overriding-auto-generated-nicknames)
* [Specify endpoint details](#details)
* [Overriding the route summary](#summary)
* [Defining an endpoint as an array](#array)
* [Using an options hash](#options)
* [Overriding param type](#overriding-param-type)
* [Overriding param types](#overriding-param-types)
* [Multiple param types](#multiple-types)
* [Array type](#array-type)
* [Collection Format](#collection-format)
* [Hiding parameters](#hiding-parameters)
* [Setting a Swagger default value](#default-value)
* [Response documentation](#response)
* [Extensions](#extensions)


<a name="headers" />
#### Swagger Header Parameters <a name="headers" />

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.

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


<a name="hiding" />
#### Hiding an Endpoint

You can hide an endpoint by adding ```hidden: true``` in the description of the endpoint:

```ruby
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:

```ruby
desc 'Conditionally hide this endpoint', hidden: lambda { ENV['EXPERIMENTAL'] != 'true' }
```


<a name="overriding-auto-generated-nicknames" />
#### 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.

```ruby
desc 'Get a full list of pets', nickname: 'getAllPets'
```


<a name="details" />
#### Specify endpoint details

To specify further details for an endpoint, use the `detail` option within a block passed to `desc`:

```ruby
desc 'Get all kittens!' do
  detail 'this will expose all the kittens'
end
get '/kittens' do
```


<a name="summary" />
#### Overriding the route summary

To override the summary, add `summary: '[string]'` after the description.

```ruby
namespace 'order' do
  desc 'This will be your summary',
    summary: 'Now this is your summary!'
  get :order_id do
    ...
  end
end
```


<a name="array" />
#### Defining an endpoint as an array

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

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


<a name="options" />
#### 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:

```ruby
desc 'Get all kittens!', {
  hidden: true,
  is_array: true,
  nickname: 'getKittens',
  success: Entities::Kitten, # or success
  failures: [[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
```


<a name="overriding-param-type" />
#### Overriding param type

You can override paramType in POST|PUT methods to query, using the documentation hash.

```ruby
params do
  requires :action, type: Symbol, values: [:PAUSE, :RESUME, :STOP], documentation: { param_type: 'query' }
end
post :act do
  ...
end
```

<a name="overriding-param-types" />
#### Overriding param types

You can override type, using the documentation hash.

```ruby
params do
  requires :input, type: String, documentation: { type: 'integer' }
end
post :act do
  ...
end
```

```json
{
  "in": "formData",
  "name": "input",
  "type": "integer",
  "format": "int32",
  "required": true
}
```


<a name="multiple-types" />
#### Multi types

By default when you set multi types, the first type is selected as swagger type

```ruby
params do
  requires :action, types: [String, Integer]
end
post :act do
  ...
end
```

```json
{
  "in": "formData",
  "name": "action",
  "type": "string",
  "required": true
}
```

<a name="array-type" />
#### Array type

Array types are also supported.

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

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


<a name="collection-format" />
#### Collection format of arrays

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

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

```json
{
  "in": "formData",
  "name": "statuses",
  "type": "array",
  "items": {
      "type": "string"
  },
  "collectionFormat": "multi",
  "required": true
}
```


<a name="hiding-parameters" />
#### Hiding parameters

Exclude single optional parameter from the documentation

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


<a name="default-value" />
#### Setting a Swagger default value

Grape allows for an additional documentation hash to be passed to a parameter.

```ruby
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.

```ruby
params do
  requires :id, type: Integer, desc: 'Coffee ID'
  optional :temperature, type: Integer, desc: 'Temperature of the coffee in celcius', default: 72
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.

```ruby
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:

```ruby
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.

```ruby
namespace 'store/order', desc: 'Order operations within a store', swagger: { nested: false, name: 'Store-orders' } do
  get :order_id do
  	...
  end
end
```


<a name="response" />
#### 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.

```ruby
desc 'thing', failures: [ { code: 400, message: "Invalid parameter entry" } ]
get '/thing' do
  ...
end
```

```ruby
desc 'thing' do
  params Entities::Something.documentation
  failures [ { code: 400, message: "Invalid parameter entry" } ]
end
get '/thing' do
  ...
end
```

```ruby
get '/thing', failures: [
  { code: 200, message: 'Ok' },
  { code: 400, message: "Invalid parameter entry" }
] do
  ...
end
```

By adding a `model` key, e.g. this would be taken.
```ruby
get '/thing', failures: [
  { code: 200, message: 'Ok' },
  { code: 422, message: "Invalid parameter entry", model: Entities::ApiError }
] do
  ...
end
```
If no status code is defined [defaults](/lib/grape-swagger/endpoint.rb#L121) would be taken.

The result is then something like following:

```json
"responses": {
  "200": {
    "description": "get Horses",
    "schema": {
      "$ref": "#/definitions/Thing"
    }
  },
  "401": {
    "description": "HorsesOutError",
    "schema": {
      "$ref": "#/definitions/ApiError"
    }
  }
},
```

<a name="extensions" />
#### 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](spec/lib/extensions_spec.rb).
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:
```ruby
desc 'This returns something with extension on verb level',
  x: { some: 'stuff' }
```
this would generate:
```json
"/path":{
  "get":{
    "…":"…",
    "x-some":"stuff"
  }
}
```

- `path` extension, by setting via route settings:
```ruby
route_setting :x_path, { some: 'stuff' }
```
this would generate:
```json
"/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:
```ruby
route_setting :x_def, { for: 422, other: 'stuff' }
```
this would generate:
```json
"/definitions":{
  "ApiError":{
    "x-other":"stuff",
    "…":"…",
  }
}
```
or, for more definitions:
```ruby
route_setting :x_def, [{ for: 422, other: 'stuff' }, { for: 200, some: 'stuff' }]
```


<a name="grape-entity" />
## Using Grape Entities

Add the [grape-entity](https://github.com/ruby-grape/grape-entity) and [grape-swagger-entity](https://github.com/ruby-grape/grape-swagger-entity) gem to your Gemfile.

The following example exposes statuses. And exposes statuses documentation adding :type and :desc.
The documented class/definition name could be set via `#entity_name`.

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

      def self.entity_name
        'LinkedStatus'
      end

    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

```ruby
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.

```ruby
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
```

<a name="oauth" />
## Securing the Swagger UI


The Swagger UI on Grape could be secured from unauthorized access using any middleware, which provides certain methods:

- some guard method, which could receive as argument a string or an array of authorization scopes;
- a *before* method to be run in the Grape controller for authorization purpose;
- a set of methods which will process the access token received in the HTTP request headers (usually in the
'HTTP_AUTHORIZATION' header) and try to return the owner of the token.

Below are some examples of securing the Swagger UI on Grape installed along with Ruby on Rails:

- 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](https://github.com/antek-drzewiecki/wine_bouncer/pull/64).

This is how to configure the grape_swagger documentation:

```ruby
  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
                            token_owner: 'resource_owner'               # This is the method returning the owner of the 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. the
access_token is being retreiving 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:

```ruby
  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:

```ruby
  not_admins = lambda { |token_owner = nil| token_owner.nil? || !token_owner.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_owner is nil by default), and has the admin
role - only admins can see this endpoint.

<a name="md_usage" />
## 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](http://kramdown.rubyforge.org) (kramdown [syntax](http://kramdown.rubyforge.org/syntax.html)) and [redcarpet](https://github.com/vmg/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:
```ruby
add_swagger_documentation \
  markdown: GrapeSwagger::Markdown::KramdownAdapter.new(options)
```
and write your route details in GFM, examples could be find in [details spec](blob/master/spec/swagger_v2/api_swagger_v2_detail_spec.rb)


#### Kramdown
If you want to use kramdown as markdown formatter, you need to add kramdown to your gemfile.

```ruby
gem 'kramdown'
```

Configure your api documentation route with:
```ruby
add_swagger_documentation \
  markdown: GrapeSwagger::Markdown::KramdownAdapter.new(options)
```


#### Redcarpet
As alternative you can use [redcarpet](https://github.com/vmg/redcarpet) as formatter, you need to include redcarpet in your gemspec. If you also want to use [rouge](https://github.com/jneen/rouge) as syntax highlighter you also need to include it.

```ruby
gem 'redcarpet'
gem 'rouge'
```

Configure your api documentation route with:

```ruby
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.


```ruby
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
```


<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

![grape-swagger-v2-new-corrected](https://cloud.githubusercontent.com/assets/1027590/13516020/979cfefa-e1f9-11e5-9624-f4a6b17a3c8a.png)

#### Example Code

```ruby
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
  …

```


<a name="rake" />
## Rake Tasks

Add these lines to your Rakefile, and initialize the Task class with your Api class – be sure your Api class is available.

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

#### OpenApi/Swagger Documentation

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

#### OpenApi/Swagger Validation

**requires**: `npm` and `swagger-cli` to be installed


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


## Contributing to grape-swagger

See [CONTRIBUTING](CONTRIBUTING.md).

## Copyright and License

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

Name		Name	Last commit message	Last commit date
Latest commit History 654 Commits
example		example
lib		lib
spec		spec
.document		.document
.gitignore		.gitignore
.rspec		.rspec
.rubocop.yml		.rubocop.yml
.rubocop_todo.yml		.rubocop_todo.yml
.ruby-gemset		.ruby-gemset
.travis.yml		.travis.yml
CHANGELOG.md		CHANGELOG.md
CONTRIBUTING.md		CONTRIBUTING.md
Dangerfile		Dangerfile
Gemfile		Gemfile
LICENSE.txt		LICENSE.txt
README.md		README.md
RELEASING.md		RELEASING.md
Rakefile		Rakefile
UPGRADING.md		UPGRADING.md
grape-swagger.gemspec		grape-swagger.gemspec

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

Table of Contents

Upgrade

Custom Model Parsers

insert_before

insert_after

CORS

About

Releases

Packages

Languages

License

anjlab/grape-swagger

Folders and files

Latest commit

History

Repository files navigation

Table of Contents

Upgrade

Custom Model Parsers

insert_before

insert_after

CORS

About

Resources

License

Stars

Watchers

Forks

Releases

Packages 0

Languages

Packages