swagger-docs

Swagger::Docs

Generates swagger-ui json files for rails apps with APIs. You add the swagger DSL to your controller classes and then run one rake task to generate the json files.

Swagger Version Specification Support

This project supports elements of the v1.2 swagger specification. It does not support the v2 specification. If you are looking for support for the newer specification the please see the swagger-blocks project. I don't currently have any plans to add support for v2.0 at this time due to time constraints, but I'm open to accepting a PR on this. Contact me if you are interested in helping with that effort - thanks!

Example usage

Here is an extract of the DSL from a user controller API class:

swagger_controller :users, "User Management"

swagger_api :index do
  summary "Fetches all User items"
  notes "This lists all the active users"
  param :query, :page, :integer, :optional, "Page number"
  response :unauthorized
  response :not_acceptable
  response :requested_range_not_satisfiable
end

Installation

Add this line to your application's Gemfile:

gem 'swagger-docs'

And then execute:

$ bundle

Or install it yourself as:

$ gem install swagger-docs

Usage

Create Initializer

Create an initializer in config/initializers (e.g. swagger_docs.rb) and define your APIs:

…

Configuration options

The following table shows all the current configuration options and their defaults. The default will be used if you don't supply your own value.

Option Description Default

api_extension_type The extension, if necessary, used for your API - e.g. :json or :xml nil

api_file_path The output file path where generated swagger-docs files are written to. public/

base_path The URI base path for your API - e.g. api.somedomain.com /

base_api_controller / base_api_controllers The base controller class your project uses; it or its subclasses will be where you call swagger_controller and swagger_api. An array of base controller classes may be provided. ActionController::Base

clean_directory When generating swagger-docs files this option specifies if the api_file_path should be cleaned first. This means that all files will be deleted in the output directory first before any files are generated. false

formatting Specifies which formatting method to apply to the JSON that is written. Available options: :none, :pretty :pretty

camelize_model_properties Camelizes property names of models. For example, a property name called first_name would be converted to firstName. true

parent_controller Assign a different controller to use for the configuration

Documenting a controller

…

Support for Enums (PR #108)

property_list :type, :string, :optional, "Type", ["info", "warning", "error"]

Custom resource paths`(PR #126)

class Api::V1::UsersController < ApplicationController

  swagger_controller :users, "User Management", resource_path: "/some/where"

DRYing up common documentation

Suppose you have a header or a parameter that must be present on several controllers and methods. Instead of duplicating it on all the controllers you can do this on your API base controller:

class Api::BaseController < ActionController::Base
  class << self
    Swagger::Docs::Generator::set_real_methods

    def inherited(subclass)
      super
      subclass.class_eval do
        setup_basic_api_documentation
      end
    end

    private
    def setup_basic_api_documentation
      [:index, :show, :create, :update, :delete].each do |api_action|
        swagger_api api_action do
          param :header, 'Authentication-Token', :string, :required, 'Authentication token'
        end
      end
    end
  end
end

And then use it as a superclass to all you API controllers. All the subclassed controllers will have the same documentation applied to them.

Alternate method

Using a block for the swagger_api definition:

…

DSL Methods

Method Description

summary The summary of the API

notes (optional) The associated notes for the API

param Standard API Parameter

param_list Standard API Enum/List parameter.

response Takes a symbol or status code and passes it to Rack::Utils.status_code. The current list of status codes can be seen here: https://github.com/rack/rack/blob/master/lib/rack/utils.rb. An optional message can be added.

Run rake task to generate docs

rake swagger:docs

Swagger-ui JSON files should now be present in your api_file_path (e.g. ./public/api/v1)

Additional logging for generation failures

Errors aren't displayed by default. To see all error messages use the SD_LOG_LEVEL environment variable when running the rake task:

SD_LOG_LEVEL=1 rake swagger:docs

Currently only constantize errors are shown.

Errors are written to $stderr. Error logging methods can be found in Config and can be overridden for custom behaviour.

Thanks to @tomtt who originally suggested this idea in #81

Sample

A sample Rails application where you can run the above rake command and view the output in swagger-ui can be found here:

https://github.com/richhollis/swagger-docs-sample

Advanced Customization

Inheriting from a custom Api controller

By default swagger-docs is applied to controllers inheriting from ApplicationController. If this is not the case for your application, use this snippet in your initializer before calling Swagger::Docs::Config#register_apis(...).

class Swagger::Docs::Config
  def self.base_api_controller; Api::ApiController end
end

Custom route discovery for supporting Rails Engines

By default, swagger-docs finds controllers by traversing routes in Rails.application. To override this, you can customize the base_application config in an initializer:

class Swagger::Docs::Config
  def self.base_application; Api::Engine end
end

If you want swagger to find controllers in Rails.application and/or multiple engines you can override base_application to return an array.

class Swagger::Docs::Config
  def self.base_application; [Rails.application, Api::Engine, SomeOther::Engine] end
end

Or, if you prefer you can override base_applications for this purpose. The plural base_applications takes precedence over base_application and MUST return an array.

class Swagger::Docs::Config
  def self.base_applications; [Rails.application, Api::Engine, SomeOther::Engine] end
end

Transforming the path variable

Swagger allows a distinction between the API documentation server and the hosted API server through the path variable (see Swagger: No server Integrations). To override the default swagger-docs behavior, you can provide a transform_path class method in your initializer:

class Swagger::Docs::Config
  def self.transform_path(path, api_version)
    "http://example.com/api-docs/#{api_version}/#{path}"
  end
end

The transformation will be applied to all API path values in the generated api-docs.json file.

Precompile

It is best-practice not to keep documentation in version control. An easy way to integrate swagger-docs into a conventional deployment setup (e.g. capistrano, chef, or opsworks) is to piggyback on the 'assets:precompile' rake task. And don't forget to add your api documentation directory to .gitignore in this case.

#Rakefile or lib/task/precompile_overrides.rake
namespace :assets do
  task :precompile do
    Rake::Task['assets:precompile'].invoke
    Rake::Task['swagger:docs'].invoke
  end
end

Output files

api-docs.json output:

{
  "apiVersion": "1.0",
  "swaggerVersion": "1.2",
  "basePath": "/api/v1",
  "apis": [
    {
      "path": "/users.{format}",
      "description": "User Management"
    }
  ]
}

users.json output:

…

Thanks to our contributors

Thanks to jdar, fotinakis, stevschmid, ldnunes, aaronrenner and all of our contributors for making swagger-docs even better.

Related Projects

@fotinakis has created Swagger::Blocks - a DSL for pure Ruby code blocks: swagger-blocks

A cors rack middleware for testing swagger apis designed to be used in Rails development environments.

More About Me

Rich Hollis

Contributing

When raising a Pull Request please ensure that you have provided good test coverage for the request you are making.

1. Fork it
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Add some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request