0.01
Repository is archived
No commit activity in last 3 years
No release in over 3 years
There's a lot of open issues
Unintrusive interactive API documentation generator for rails apps
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Project Readme

Gem Version Build Status Code Climate Test Coverage

About

RocketDocs is a automatic documentation generator for APIs.

It is intended to be used with 🚀 rocket_pants based APIs but it can also be used as a standalone generator through rake tasks.

This project was mostly inspired by the 🍇 grape-swagger project.

All documentation is done in comments so that your code doesn't get littered with code that has no functional purpose, thus making your code more readable.

Example: Before After

Table of contents

  1. About
  2. Installation
  3. With RocketPants
  4. With Rake
  5. Configuration
  6. Usage
  7. Keywords 1. DOC 2. PARAMS 3. URL 4. GET, PUT, POST, PATCH, DELETE
  8. Rake task
  9. Differences between engine and rake task use
  10. Code Examples
  11. Contributing
  12. License

Installation

# In your Gemfile
gem 'rocket_docs'

If you are using RocketPants

If you are using rocket_pants you only have to mount the engine in your routes file.

# In your config/routes.rb
mount RocketDocs::Engine => '/api-doc'

If you are NOT using RocketPants

The gem also adds two new rake tasks for generating documentation as static html or markdown files

# For HTML files
rake rocket_docs:generate[version_name, input_files, output_folder]
# Alias
rake rocket_docs:gen[version_name, input_files, output_folder]
# For MARKDOWN files
rake rocket_docs:generate_markdown[version_name, input_files, output_folde]
# Aliases
rake rocket_docs:generate_md[version_name, input_files, output_folde]
rake rocket_docs:gen_md[version_name, input_files, output_folde]

Configuration

Basically no configuration is needed. By default every api route from your routes file will be used when generating the documentation.

It's important to note that only methods that are accessible (are used in the routes file) will get documented.

To change the title or description of the generated API you can ether use an initializer or the engine setup method.

Initializer:

A config/initializers/rocket_docs.rb has to be created!

# In your config/routes.rb
mount RocketDocs::Engine => '/api-doc'

# In config/initializers/rocket_docs.rb
RocketDocs.config do |docs|
  docs.title = 'Custom API title'
  docs.description = 'Custom API description'
end

Engine setup:

# In your config/routes.rb
mount (
  RocketDocs::Engine.setup do |docs|
    docs.url = '/api-doc'
    docs.title = 'Custom API title'
    docs.description = 'Custom API description'
  end
)

Usage

If you are using rocket_pants, after you mount the engine in your routes file the only thing you have to do is write some comments in front of the method you want to document.

Remeber indentation is important!

Keywords

There are a few keywords to help you: DOC, PARAMS, URL, GET, PUT, POST, PATCH, DELETE

It doesn't matter if the words are lower or upper case.

DOC

DOC is used to define documentation, text that describes the action.

Example:

# Doc
#   This action lists all posts
#

def index
  ...
end

PARAMS

PARAMS is used to define which parameters the action accepts. If you are using rocket_pants this will be automatically populated. Note that nested parameters are allowed.

Example:

# Doc
#   This action displays a single post
#
# Params
#   id: integer (the post's identifier)
#   additional
#     author_id: integer
#     release_date: date
#

def show
  ...
end

URL

URL is used to define an action's URL. Parameters should be surounded by curly braces. If you are using rocket_pants this will be automatically populated.

Example:

# Doc
#   This action displays a single post
# URL
#   /post/{id}
# Params
#   id: integer (the post's identifier)
#

def show
  ...
end

GET, PUT, POST, PATCH, DELETE

GET, PUT, POST, PATCH, DELETE are used to define method specifics.

# GET
#   Doc
#     This action returns a users current location
#   Params
#     id: integer (the user's identifier)
# POST
#   Doc
#     This action sets a users location
#   Params
#     id: integer (the user's identifier)
#     lon: float
#     lat: gloat

def user_location
  ...
end

For the above example you could also write:

# Doc
#   This action returns a users current location
# Params
#   id: integer (the user's identifier)
#
# POST
#   Doc
#     This action sets a users location
#   Params
#     id: integer (the user's identifier)
#     lon: float
#     lat: gloat

def user_location
  ...
end

This would set the DOC, PARAMS and URL values as default values for all methods except for POST which has it's own DOC and PARAMS values.

Rake task

The rake tasks accept three arguments. A version name, a list of file paths separated by spaces and an output folder. The output folder is optional, if no output folder is defined then it will default to route_to_your_rails_app/public/system/documentation

Example:

rake rocket_docs:generate['Legacy','app/controllers/api/v1/people_controller.rb app/controllers/api/v2/posts_controller.rb','public/system/api-docs']

This would generate a Legacy.html file in your public/system/api-docs folder and you could access it by going to http://localhost:3000/system/api-docs/Legacy.html

Difference between the engine and the rake tasks

There is a difference between using the rake tasks and the engine.

When using the engine in combination with rocketpants there is no need to define to which methods the action responds to and what it's URL is. So if you have an action that responds to both GET and POST requests you only have to write the following and it would automatically detect to which methods the action responds and what it's URL is.

# Doc
#   This action returns a users current location
# Params
#   id: integer (the user's identifier)

def user_location
  ...
end

But the rake tasks are not able to determine the URL and to which methods an action responds so they have to be explicitly specified! To get the same result as in the above example you would have to write:

# URL
#   /users/location?id={id}
# Doc
#   This action returns a users current location
# Params
#   id: integer (the user's identifier)
# GET
# POST

def user_location
  ...
end

Note: If no new value was defined in a method specific block then the default will be used

Code examples

Currently the best example you can look at is the test_app located in the specs folder. You can even start the app and experiment a little bit.

Contributing

If you want to help this project out please fell free to:

  1. Fork this repo
  2. Make changes
  3. Write tests
  4. Issue a pull request with an explanation

Or open an issue here.

License

This project rocks and uses MIT-LICENSE.