Code Monkey home page Code Monkey logo

rspec_api_documentation's Introduction

Code Climate Inline docs Gem Version

RSpec API Doc Generator

Generate pretty API docs for your Rails APIs.

Check out a sample.

Changes

Please see the wiki for latest changes.

Installation

Add rspec_api_documentation to your Gemfile

gem 'rspec_api_documentation'

Bundle it!

$ bundle install

Set up specs.

$ mkdir spec/acceptance
$ vim spec/acceptance/orders_spec.rb
require 'rails_helper'
require 'rspec_api_documentation/dsl'

resource "Orders" do
  get "/orders" do
    example "Listing orders" do
      do_request

      expect(status).to eq 200
    end
  end
end

Generate the docs!

$ rake docs:generate
$ open doc/api/index.html

Viewers

Consider adding a viewer to enhance the generated documentation. By itself rspec_api_documentation will generate very simple HTML. All viewers use the generated JSON.

Gemfile

gem 'raddocs'

or 

gem 'apitome'

spec/spec_helper.rb

RspecApiDocumentation.configure do |config|
  config.format = :json
end

For both raddocs and apitome, start rails server. Then

open http://localhost:3000/docs for raddocs

or

http://localhost:3000/api/docs for apitome

Sample App

See the example folder for a sample Rails app that has been documented. The sample app demonstrates the :open_api format.

Example of spec file

  # spec/acceptance/orders_spec.rb
  require 'rails_helper'
  require 'rspec_api_documentation/dsl'
  resource 'Orders' do
    explanation "Orders resource"
    
    header "Content-Type", "application/json"

    get '/orders' do
      # This is manual way to describe complex parameters
      parameter :one_level_array, type: :array, items: {type: :string, enum: ['string1', 'string2']}, default: ['string1']
      parameter :two_level_array, type: :array, items: {type: :array, items: {type: :string}}
      
      let(:one_level_array) { ['string1', 'string2'] }
      let(:two_level_array) { [['123', '234'], ['111']] }

      # This is automatic way
      # It's possible because we extract parameters definitions from the values
      parameter :one_level_arr, with_example: true
      parameter :two_level_arr, with_example: true

      let(:one_level_arr) { ['value1', 'value2'] }
      let(:two_level_arr) { [[5.1, 3.0], [1.0, 4.5]] }

      context '200' do
        example_request 'Getting a list of orders' do
          expect(status).to eq(200)
        end
      end
    end

    put '/orders/:id' do

      with_options scope: :data, with_example: true do
        parameter :name, 'The order name', required: true
        parameter :amount
        parameter :description, 'The order description'
      end

      context "200" do
        let(:id) { 1 }

        example 'Update an order' do
          request = {
            data: {
              name: 'order',
              amount: 1,
              description: 'fast order'
            }
          }
          
          # It's also possible to extract types of parameters when you pass data through `do_request` method.
          do_request(request)
          
          expected_response = {
            data: {
              name: 'order',
              amount: 1,
              description: 'fast order'
            }
          }
          expect(status).to eq(200)
          expect(response_body).to eq(expected_response)
        end
      end

      context "400" do
        let(:id) { "a" }

        example_request 'Invalid request' do
          expect(status).to eq(400)
        end
      end
      
      context "404" do
        let(:id) { 0 }
        
        example_request 'Order is not found' do
          expect(status).to eq(404)
        end
      end
    end
  end

Configuration options

# Values listed are the default values
RspecApiDocumentation.configure do |config|
  # Set the application that Rack::Test uses
  config.app = Rails.application

  # Used to provide a configuration for the specification (supported only by 'open_api' format for now) 
  config.configurations_dir = Rails.root.join("doc", "configurations", "api")

  # Output folder
  # **WARNING*** All contents of the configured directory will be cleared, use a dedicated directory.
  config.docs_dir = Rails.root.join("doc", "api")

  # An array of output format(s).
  # Possible values are :json, :html, :combined_text, :combined_json,
  #   :json_iodocs, :textile, :markdown, :append_json, :slate,
  #   :api_blueprint, :open_api
  config.format = [:html]

  # Location of templates
  config.template_path = "inside of the gem"

  # Filter by example document type
  config.filter = :all

  # Filter by example document type
  config.exclusion_filter = nil

  # Used when adding a cURL output to the docs
  config.curl_host = nil

  # Used when adding a cURL output to the docs
  # Allows you to filter out headers that are not needed in the cURL request,
  # such as "Host" and "Cookie". Set as an array.
  config.curl_headers_to_filter = nil

  # By default, when these settings are nil, all headers are shown,
  # which is sometimes too chatty. Setting the parameters to an
  # array of headers will render *only* those headers.
  config.request_headers_to_include = nil
  config.response_headers_to_include = nil

  # By default examples and resources are ordered by description. Set to true keep
  # the source order.
  config.keep_source_order = false

  # Change the name of the API on index pages
  config.api_name = "API Documentation"
  
  # Change the description of the API on index pages
  config.api_explanation = "API Description"

  # Redefine what method the DSL thinks is the client
  # This is useful if you need to `let` your own client, most likely a model.
  config.client_method = :client

  # Change the IODocs writer protocol
  config.io_docs_protocol = "http"

  # You can define documentation groups as well. A group allows you generate multiple
  # sets of documentation.
  config.define_group :public do |config|
    # By default the group's doc_dir is a subfolder under the parent group, based
    # on the group's name.
    # **WARNING*** All contents of the configured directory will be cleared, use a dedicated directory.
    config.docs_dir = Rails.root.join("doc", "api", "public")

    # Change the filter to only include :public examples
    config.filter = :public
  end

  # Change how the post body is formatted by default, you can still override by `raw_post`
  # Can be :json, :xml, or a proc that will be passed the params
  config.request_body_formatter = Proc.new { |params| params }

  # Change how the response body is formatted by default
  # Is proc that will be called with the response_content_type & response_body
  # by default, a response body that is likely to be binary is replaced with the string
  # "[binary data]" regardless of the media type.  Otherwise, a response_content_type of `application/json` is pretty formatted.
  config.response_body_formatter = Proc.new { |response_content_type, response_body| response_body }

  # Change the embedded style for HTML output. This file will not be processed by
  # RspecApiDocumentation and should be plain CSS.
  config.html_embedded_css_file = nil

  # Removes the DSL method `status`, this is required if you have a parameter named status
  # In this case you can assert response status with `expect(response_status).to eq 200`
  config.disable_dsl_status!

  # Removes the DSL method `method`, this is required if you have a parameter named method
  config.disable_dsl_method!
end

Format

  • json: Generates an index file and example files in JSON.
  • html: Generates an index file and example files in HTML.
  • combined_text: Generates a single file for each resource. Used by Raddocs for command line docs.
  • combined_json: Generates a single file for all examples.
  • json_iodocs: Generates I/O Docs style documentation.
  • textile: Generates an index file and example files in Textile.
  • markdown: Generates an index file and example files in Markdown.
  • api_blueprint: Generates an index file and example files in APIBlueprint.
  • append_json: Lets you selectively run specs without destroying current documentation. See section below.
  • slate: Builds markdown files that can be used with Slate, a beautiful static documentation builder.
  • open_api: Generates OpenAPI Specification (OAS) (Current supported version is 2.0). Can be used for Swagger-UI

append_json

This format cannot be run with other formats as they will delete the entire documentation folder upon each run. This format appends new examples to the index file, and writes all run examples in the correct folder.

Below is a rake task that allows this format to be used easily.

RSpec::Core::RakeTask.new('docs:generate:append', :spec_file) do |t, task_args|
  if spec_file = task_args[:spec_file]
    ENV["DOC_FORMAT"] = "append_json"
  end
  t.pattern    = spec_file || 'spec/acceptance/**/*_spec.rb'
  t.rspec_opts = ["--format RspecApiDocumentation::ApiFormatter"]
end

And in your spec/spec_helper.rb:

ENV["DOC_FORMAT"] ||= "json"

RspecApiDocumentation.configure do |config|
  config.format    = ENV["DOC_FORMAT"]
end
rake docs:generate:append[spec/acceptance/orders_spec.rb]

This will update the current index's examples to include any in the orders_spec.rb file. Any examples inside will be rewritten.

api_blueprint

This format (APIB) has additional functions:

  • route: APIB groups URLs together and then below them are HTTP verbs.

    route "/orders", "Orders Collection" do
      get "Returns all orders" do
        # ...
      end
    
      delete "Deletes all orders" do
        # ...
      end
    end

    If you don't use route, then param in get(param) should be an URL as states in the rest of this documentation.

  • attribute: APIB has attributes besides parameters. Use attributes exactly like you'd use parameter (see documentation below).

open_api

This format (OAS) has additional functions:

  • authentication(type, value, opts = {}) (Security schema object)

    The values will be passed through header of the request. Option name has to be provided for apiKey.

    • authentication :basic, 'Basic Key'
    • authentication :apiKey, 'Api Key', name: 'API_AUTH', description: 'Some description'

    You could pass Symbol as value. In this case you need to define a let with the same name.

    authentication :apiKey, :api_key
    let(:api_key) { some_value } 
    
  • route_summary(text) and route_description(text). (Operation object)

    These two simplest methods accept String. It will be used for route's summary and description.

  • Several new options on parameter helper.

    • with_example: true. This option will adjust your example of the parameter with the passed value.
    • example: <value>. Will provide a example value for the parameter.
    • default: <value>. Will provide a default value for the parameter.
    • minimum: <integer>. Will setup upper limit for your parameter.
    • maximum: <integer>. Will setup lower limit for your parameter.
    • enum: [<value>, <value>, ..]. Will provide a pre-defined list of possible values for your parameter.
    • type: [:file, :array, :object, :boolean, :integer, :number, :string]. Will set a type for the parameter. Most of the type you don't need to provide this option manually. We extract types from values automatically.

You also can provide a configuration file in YAML or JSON format with some manual configs. The file should be placed in configurations_dir folder with the name open_api.yml or open_api.json. In this file you able to manually hide some endpoints/resources you want to hide from generated API specification but still want to test. It's also possible to pass almost everything to the specification builder manually.

Example of configuration file

swagger: '2.0'
info:
  title: OpenAPI App
  description: This is a sample server.
  termsOfService: 'http://open-api.io/terms/'
  contact:
    name: API Support
    url: 'http://www.open-api.io/support'
    email: [email protected]
  license:
    name: Apache 2.0
    url: 'http://www.apache.org/licenses/LICENSE-2.0.html'
  version: 1.0.0
host: 'localhost:3000'
schemes:
  - http
  - https
consumes:
  - application/json
  - application/xml
produces:
  - application/json
  - application/xml
paths: 
  /orders:
    hide: true
  /instructions:
    hide: false
    get:
      description: This description came from configuration file
      hide: true

Example of spec file with :open_api format

  resource 'Orders' do
    explanation "Orders resource"
    
    authentication :apiKey, :api_key, description: 'Private key for API access', name: 'HEADER_KEY'
    header "Content-Type", "application/json"
    
    let(:api_key) { generate_api_key }

    get '/orders' do
      route_summary "This URL allows users to interact with all orders."
      route_description "Long description."

      # This is manual way to describe complex parameters
      parameter :one_level_array, type: :array, items: {type: :string, enum: ['string1', 'string2']}, default: ['string1']
      parameter :two_level_array, type: :array, items: {type: :array, items: {type: :string}}
      
      let(:one_level_array) { ['string1', 'string2'] }
      let(:two_level_array) { [['123', '234'], ['111']] }

      # This is automatic way
      # It's possible because we extract parameters definitions from the values
      parameter :one_level_arr, with_example: true
      parameter :two_level_arr, with_example: true

      let(:one_level_arr) { ['value1', 'value2'] }
      let(:two_level_arr) { [[5.1, 3.0], [1.0, 4.5]] }

      context '200' do
        example_request 'Getting a list of orders' do
          expect(status).to eq(200)
          expect(response_body).to eq(<response>)
        end
      end
    end

    put '/orders/:id' do
      route_summary "This is used to update orders."

      with_options scope: :data, with_example: true do
        parameter :name, 'The order name', required: true
        parameter :amount
        parameter :description, 'The order description'
      end

      context "200" do
        let(:id) { 1 }

        example 'Update an order' do
          request = {
            data: {
              name: 'order',
              amount: 1,
              description: 'fast order'
            }
          }
          
          # It's also possible to extract types of parameters when you pass data through `do_request` method.
          do_request(request)
          
          expected_response = {
            data: {
              name: 'order',
              amount: 1,
              description: 'fast order'
            }
          }
          expect(status).to eq(200)
          expect(response_body).to eq(<response>)
        end
      end

      context "400" do
        let(:id) { "a" }

        example_request 'Invalid request' do
          expect(status).to eq(400)
        end
      end
      
      context "404" do
        let(:id) { 0 }
        
        example_request 'Order is not found' do
          expect(status).to eq(404)
        end
      end
    end
  end

Filtering and Exclusion

rspec_api_documentation lets you determine which examples get outputted into the final documentation. All filtering is done via the :document metadata key. You tag examples with either a single symbol or an array of symbols. :document can also be false, which will make sure it does not get outputted.

resource "Account" do
  get "/accounts" do
    parameter :page, "Page to view"

    # default :document is :all
    example "Get a list of all accounts" do
      do_request
      expect(status).to eq 200
    end

    # Don't actually document this example, purely for testing purposes
    example "Get a list on page 2", :document => false do
      do_request(:page => 2)
      expect(status).to eq 404
    end

    # With example_request, you can't change the :document
    example_request "Get a list on page 3", :page => 3 do
      expect(status).to eq 404
    end
  end

  post "/accounts" do
    parameter :email, "User email"

    example "Creating an account", :document => :private do
      do_request(:email => "[email protected]")
      expect(status).to eq 201
    end

    example "Creating an account - errors", :document => [:private, :developers] do
      do_request
      expect(status).to eq 422
    end
  end
end
# All documents will be generated into the top folder, :document => false
# examples will never be generated.
RspecApiDocumentation.configure do |config|
  # Exclude only document examples marked as 'private'
  config.define_group :non_private do |config|
    config.exclusion_filter = :private
  end

  # Only document examples marked as 'public'
  config.define_group :public do |config|
    config.filter = :public
  end

  # Only document examples marked as 'developer'
  config.define_group :developers do |config|
    config.filter = :developers
  end
end

DSL

Require the DSL

At the beginning of each acceptance/*_spec.rb file, make sure to require the following to pull in the DSL definitions:

require 'rspec_api_documentation/dsl'

Example Group Methods

resource

Create a set of documentation examples that go together. Acts as a describe block.

resource "Orders" do
end

get, head, post, put, delete, patch

The method that will be sent along with the url.

resource "Orders" do
  post "/orders" do
  end

  get "/orders" do
  end

  head "/orders" do
  end

  put "/orders/:id" do
    let(:id) { order.id }

    example "Get an order" do
      expect(path).to eq "/orders/1" # `:id` is replaced with the value of `id`
    end
  end

  delete "/orders/:id" do
  end

  patch "/orders/:id" do
  end
end

example

This is just RSpec's built in example method, we hook into the metadata surrounding it. it could also be used.

resource "Orders" do
  post "/orders" do
    example "Creating an order" do
      do_request
      # make assertions
    end
  end
end

example_request

The same as example, except it calls do_request as the first step. Only assertions are required in the block.

Similar to do_request you can pass in a hash as the last parameter that will be passed along to do_request as extra parameters. These will not become metadata like with example.

resource "Orders" do
  parameter :name, "Order name"

  post "/orders" do
    example_request "Creating an order", :name => "Other name" do
      # make assertions
    end
  end
end

explanation

This method takes a string representing a detailed explanation of the example.

resource "Orders" do
  post "/orders" do
    example "Creating an order" do
      explanation "This method creates a new order."
      do_request
      # make assertions
    end
  end
end

A resource can also have an explanation.

resource "Orders" do
  explanation "Orders are top-level business objects. They can be created by a POST request"
  post "/orders" do
    example "Creating an order" do
      explanation "This method creates a new order."
      do_request
      # make assertions
    end
  end
end

header

This method takes the header name and value. The value can be a string or a symbol. If it is a symbol it will send the symbol, allowing you to let header values.

resource "Orders" do
  header "Accept", "application/json"
  header "X-Custom", :custom_header

  let(:custom_header) { "dynamic" }

  get "/orders" do
    example_request "Headers" do
      expect(headers).to eq { "Accept" => "application/json", "X-Custom" => "dynamic" }
    end
  end
end

parameter

This method takes the parameter name, a description, and an optional hash of extra metadata that can be displayed in Raddocs as extra columns. If a method with the parameter name exists, e.g. a let, it will send the returned value up to the server as URL encoded data.

Special values:

  • :required => true Will display a red '*' to show it's required
  • :scope => :the_scope Will scope parameters in the hash, scoping can be nested. See example
  • :method => :method_name Will use specified method as a parameter value

Retrieving of parameter value goes through several steps:

  1. if method option is defined and test case responds to this method then this method is used;
  2. if test case responds to scoped method then this method is used;
  3. overwise unscoped method is used.
resource "Orders" do
  parameter :auth_token, "Authentication Token"

  let(:auth_token) { user.authentication_token }

  post "/orders" do
    parameter :name, "Order Name", :required => true, :scope => :order
    parameter :item, "Order items", :scope => :order
    parameter :item_id, "Item id", :scope => [:order, :item], method: :custom_item_id

    let(:name) { "My Order" }
    # OR let(:order_name) { "My Order" }
    let(:item_id) { 1 }
    # OR let(:custom_item_id) { 1 }
    # OR let(:order_item_item_id) { 1 }

    example "Creating an order" do
      expect(params).to eq({
        :order => {
          :name => "My Order",
          :item => {
            :item_id => 1,
          }
        },
        :auth_token => auth_token,
      })
    end
  end
end

response_field

This method takes the response field name, a description, and an optional hash of extra metadata that can be displayed in Raddocs as extra columns.

Special values:

  • :scope => :the_scope Will scope the response field in the hash
resource "Orders" do
  response_field :page, "Current page"

  get "/orders" do
    example_request "Getting orders" do
      expect(response_body).to eq({ :page => 1 }.to_json)
    end
  end
end

You can also group metadata using with_options to factor out duplications.

resource "Orders" do
  post "/orders" do

    with_options :scope => :order, :required => true do
      parameter :name, "Order Name"
      parameter :item, "Order items"
    end

    with_options :scope => :order do
      response_field :id, "Order ID"
      response_field :status, "Order status"
    end

    let(:name) { "My Order" }
    let(:item_id) { 1 }

    example "Creating an order" do
      expect(status).to be 201
    end
  end
end

callback

This is complicated, see relish docs.

trigger_callback

Pass this method a block which, when evaluated, will cause the application to make a request to callback_url.

Example methods

callback_url

Defines the destination of the callback.

For an example, see relish docs.

client

Returns the test client which makes requests and documents the responses.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      # Create an order via the API instead of via factories
      client.post "/orders", order_hash

      do_request

      expect(status).to eq 200
    end
  end
end

do_callback

This will evaluate the block passed to trigger_callback, which should cause the application under test to make a callback request. See relish docs.

do_request

Sends the request to the app with any parameters and headers defined.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      do_request

      expect(status).to eq 200
    end
  end
end

no_doc

If you wish to make a request via the client that should not be included in your documentation, do it inside of a no_doc block.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      no_doc do
        # Create an order via the API instead of via factories, don't document it
        client.post "/orders", order_hash
      end

      do_request

      expect(status).to eq 200
    end
  end
end

params

Get a hash of parameters that will be sent. See parameter documentation for an example.

header

This method takes the header name and value.

resource "Orders" do
  before do
    header "Accept", "application/json"
  end

  get "/orders" do
    example_request "Headers" do
      expect(headers).to eq { "Accept" => "application/json" }
    end
  end
end

headers

This returns the headers that were sent as the request. See header documentation for an example.

response_body

Returns a string containing the response body from the previous request.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      do_request

      expect(response_body).to eq [{ :name => "Order 1" }].to_json
    end
  end
end

response_headers

Returns a hash of the response headers from the previous request.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      do_request

      expect(response_headers["Content-Type"]).to eq "application/json"
    end
  end
end

status, response_status

Returns the numeric status code from the response, eg. 200. response_status is an alias to status because status is commonly a parameter.

resource "Order" do
  get "/orders" do
    example "Listing orders" do
      do_request

      expect(status).to eq 200
      expect(response_status).to eq 200
    end
  end
end

query_string

Data that will be sent as a query string instead of post data. Used in GET requests.

resource "Orders" do
  parameter :name

  let(:name) { "My Order" }

  get "/orders" do
    example "List orders" do
      expect(query_string).to eq "name=My+Orders"
    end
  end
end

raw_post

You can completely override what gets sent as parameters by let-ing raw_post.

resource "Orders" do
  header "Content-Type", "application/json"

  parameter :name

  let(:name) { "My Order" }

  post "/orders" do
    let(:raw_post) { params.to_json }

    example_request "Create new order" do
      # params get sent as JSON
    end
  end
end

Rake Task

The gem contains a Railtie that defines a rake task for generating docs easily with Rails. It loads all files in spec/acceptance/**/*_spec.rb.

$ rake docs:generate

If you are not using Rails, you can use Rake with the following Task:

require 'rspec/core/rake_task'

desc 'Generate API request documentation from API specs'
RSpec::Core::RakeTask.new('docs:generate') do |t|
  t.pattern = 'spec/acceptance/**/*_spec.rb'
  t.rspec_opts = ["--format RspecApiDocumentation::ApiFormatter"]
end

or

require 'rspec_api_documentation'
load 'tasks/docs.rake'

If you are not using Rake:

$ rspec spec/acceptance --format RspecApiDocumentation::ApiFormatter

Uploading a file

For an example on uploading a file see examples/spec/acceptance/upload_spec.rb.

Gotchas

  • rspec_api_documentation relies on a variable client to be the test client. If you define your own client please configure rspec_api_documentation to use another one, see Configuration above.
  • We make heavy use of RSpec metadata, you can actually use the entire gem without the DSL if you hand write the metadata.
  • You must use response_body, status, response_content_type, etc. to access data from the last response. You will not be able to use response.body or response.status as the response object will not be created.

rspec_api_documentation's People

Contributors

aadityataparia avatar bf4 avatar brandonmathis avatar davidstosik avatar denyago avatar dependabot[bot] avatar e1337kat avatar erol avatar hanachin avatar ianks avatar jakehow avatar joel avatar jonathanpa avatar jsmestad avatar keram avatar kurko avatar llenodo avatar marnen avatar mataki avatar mecampbellsoup avatar mrbrdo avatar myabc avatar oestrich avatar potomak avatar prikha avatar rpocklin avatar samwgoldman avatar sineed avatar terry90 avatar tildewill avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rspec_api_documentation's Issues

Data in cURL examples is not quoted properly

The cURL examples genreated when doing a POST or PUT don't properly quote the data associated with the -d flag.

For example, the rad-example app has the following cURL example for creating an order:

curl "http://rad-example.herokuapp.com/orders" -d "{"order":{"name":"Order 1","paid":true,"email":"[email protected]"}}" -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "Host: example.org" -H "Cookie: "

source: http://rad-example.herokuapp.com/docs/orders/creating_an_order

If you copy/paste that example it'll fail because the data uses all double quotes. Instead the outer quotes should be single quotes such as:

-d '{"order":{"name":"Order 1","paid":true,"email":"[email protected]"}}'

Pluggable test client backends

Right now we use rack/test, which gets included in every resource context and injected into TestClient as "session." We should provide a configuration option to use something other than rack/test. For example, someone using rest-client should be able to run the tests against a live server.

Add section for business logic

Usually there is some amount of business logic attached to a request - eg, "Orders can't have more than 20 items" or something - would be nice if there was a place in the documentation for that.

Clearly distinguish between routes

Each route should be clearly delineated (with the 2nd biggest heading on the page, or with an <hr> or something)

It would also be nice if each route had an English-readable summary of what it did, eg "POST /orders" creates a new order.

Update path parameters from do_request

Given the following

get "/orders/:id" do
let(:id) { 1 }

example "Another order" do
do_request(:id => 2)
end
end

The path is not updated to reflect the new id

Curl command - line up the Header params

It would be nice in the curl command if the headers lined up - just makes it a little easier to scan. So instead of:

curl "http://rad-example.herokuapp.com/orders" -d "{"order":{"name":"Order 1","paid":true,"email":"[email protected]"}}" -X POST -H "Accept: application/json" -H "Content-Type: application/json" -H "Host: example.org" -H "Cookie: "

you'd have:

curl "http://rad-example.herokuapp.com/orders" -d "{"order":{"name":"Order 1","paid":true,"email":"[email protected]"}}" -X POST \
    -H "Accept: application/json" \
    -H "Content-Type: application/json" \
    -H "Host: example.org" \
    -H "Cookie: "

Also it's a little odd that the host doesn't match the domain in the URL, although thit might be harder to fix.

License

Under what license is this code released?

Excluding rspec shared examples from generated documentation

Hey all!

First off, thanks so much for this gem! It's saving me a lot of time working with consumers of an API I'm prototyping!

That being said, I've currently having trouble configuring rspec_api_documentation; specifically the filter and exclude_filter options in RspecApiDocumentation ::Configuration.

My use case is as follows: I have a set of shared examples that look something like this:

shared_examples "an api endpoint", standard_response: true do
  example_request "should respond with HTTP 200" do
    status.should == 200
    response_body.should =~ /"status": 200/
  end

  example_request "should return a response with a json mime type" do
    response_headers["Content-Type"].should == "application/json; charset=utf-8"
  end
end

It's useful to me to have these run for a variety of examples. Unfortunately, these examples are not at all helpful when they're included in the generated documentation. I've attempted to exclude them by adding document: false and later document: :private with the corresponding exclude filter configuration. Neither has worked out too well for me.

TLDR: How do I exclude shared examples from the generated documentation (rake docs:generate)?

Thanks for your time, and awesome work with this gem!

Don't pollute RSpec metadata

Right now we store all of our metadata directly in the RSpec metadata hash. To avoid possible collisions with existing metadata uses, we should store all of our metadata under a single key.

cURL examples have host and cookies by default

This shouldn't be the case, otherwise you get confusing examples such as:

curl "https://foo.com/orders.json" -X GET -H "Accept: application/json" -H "Content-Type: application/json" -H "Host: example.org" -H "Cookie: "

Those two headers really confuse people when they read through the docs. Is there any real value added in having them, as is?

unable to set REMOTE_ADDR in rack env

I'm trying to set the HTTP_REMOTE_ADDR header to test accessing the API as a remote user. This worked fine with RSpec request specs, but broke upon converting to rspec_api_documentation.

Looking at the request.env that the controller gets, I saw that REMOTE_ADDR was "127.0.0.1", while HTTP_REMOTE_ADDR was the desired value. I eventually traced the problem back to Rack::Test::Session#default_env, which sets REMOTE_ADDR, and RspecApiDocumentation::Headers#headers_to_env which make it impossible to set REMOTE_ADDR.

I'm not entirely sure that it's rspec_api_documentation's responsibility to override REMOTE_ADDR, but it seems like the most plausible possibility since other test libraries use Rack::Test without this problem.

The following monkey patch works around the issue for me:

module RspecApiDocumentation::Headers
  def headers_to_env_with_remote_addr_fix headers
    env = headers_to_env_without_remote_addr_fix(headers)
    env["REMOTE_ADDR"] = env["HTTP_REMOTE_ADDR"] if env["HTTP_REMOTE_ADDR"]
    env
  end
  alias_method_chain :headers_to_env, :remote_addr_fix
end

Add the ability to configure a host

When an API only responds to calls on a given subdomain, it seems the full url must be specified in the example group. It would be preferable to specify the api host in the configuration instead.

URI.escape should be invoked on parameters to deal with Unicode / UTF-8

Hello again! 馃榾

Parameters passed to POST/PUT should be URI.escaped, for instance in this example the line

let(:auth_token) { user.authentication_token }

should actually say

let(:auth_token) { URI.escape user.authentication_token }

This is important when the parameter includes UTF-8 (or non-ASCII characters), and here is how to prove it. In your Rails /example, add # encoding: UTF-8 at the top, then change this line from

let(:name) { "Order 1" }

to

let(:name) { "Order W铆th 脷nic贸de 1" }

and run rake docs:generate.

The documentation will then include the following cURL example:

curl "http://localhost:3000/orders" -d '{"order":{"name":"Order W\u00edth \u00danic\u00f3de 1","paid":true,"email":"[email protected]"}}' -X POST

which is incorrect, because it POSTs an order with name Order W\u00edth \u00danic\u00f3de 1.

Instead, if you use URI.encode, then the documentation would output:

curl "http://localhost:3000/orders" -d '{"order":{"name":"Order%20W%C3%ADth%20%C3%9Anic%C3%B3de%201","paid":true,"email":"[email protected]"}}' -X POST 

which is correct, because it POSTs an order with name Order W铆th 脷nic贸de 1

Strip down outputted HTML

Remove any requirement for asset management from RAD. It's something that RAD shouldn't care about. Raddocs does a much better job at this anyways.

Including non-alphanumeric strings in header params causes parse error when ActionDispatch::ParamsParser is included

For instance header "Content-Type", "application/json" causes:

ActionDispatch::ParamsParser::ParseError:
       unexpected character at line 1, column 1 [parse.c:625]
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/actionpack-4.0.0/lib/action_dispatch/middleware/params_parser.rb:53:in `rescue in parse_formatted_parameters'
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/actionpack-4.0.0/lib/action_dispatch/middleware/params_parser.rb:32:in `parse_formatted_parameters'
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/actionpack-4.0.0/lib/action_dispatch/middleware/params_parser.rb:23:in `call'
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/activerecord-4.0.0/lib/active_record/query_cache.rb:36:in `call'
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/activerecord-4.0.0/lib/active_record/connection_adapters/abstract/connection_pool.rb:626:in `call'
     # /Users/Aerlinger/.rvm/gems/ruby-1.9.3-p362/gems/actionpack-4.0.0/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'

Any way around this without disabling the ParamsParser middleware?

Allow easier parameter overrides

The idea here is to let users pass parameters into client.(get|put|post|delete) and also do_request, which would then override the parameters defined in the example group.

This would make it easier to write degenerate cases, which currently need to be wrapped in a context so we can override.

Allow for use of rspec-mocks

I'd like to stub or mock certain objects and classes such that when I generate the API documentation I don't have to hit external services.

Resource representation assertions using schema formats

In order to help a consumer of my API know what fields mean
In order to validate responses match schema

RspecApiDocumentation.configure do |config|
  config.schema_dir = "schemas"
end

resource "Order" do
  representation "application/json", "order_schema.json"

  get "/orders/1" do
    example_request "How can we validate the response body against the schema?" do
      status.should eq(200)
      response_body.should be_valid_schema
    end
  end
end

Links:
http://tools.ietf.org/html/draft-zyp-json-schema-03
https://github.com/hoxworth/json-schema

Set a default app for Rack::Test

Rack::Test needs example groups to define an "app" method. This is easy enough to do, but we should be nice and default this to Rails.application (if Rails is defined).

There should also be a configuration option to override this across all API doc specs.

Users should still be able to override the app per example group by defining "app."

Unable to set headers in before block

I wanted to use the typical RSpec before filters, so I tagged several of my resources as:

resource_spec.rb

resource "Resource Name", api: :json do
  # specs...
end

spec_helper.rb

RSpec.configure do |config|
  config.before(:each, api: :json) do
    header 'Authorization', "Bearer [access token]"
    header 'Content-Type', 'application/json'
    header 'Accept', 'application/json'
  end
end

It fails on the header, because that's part of the DSL, and doesn't seem to be available any other way. I dug around a good bit, but there doesn't seem to be a way to specify headers/params within a before filter -- which would be nice, because I have to duplicate this at the top of all of the specs.

Thanks for a great library, it's been working really well for me and has been a pleasure to work with.

DSL discussion: expected attributes

In the same way that the DSL ensures that the API is called with the right parameters (required or not), have you ever thought of adding an expected_attributes method?

If your API returns a JSON, wouldn't it be nice to know (and to enforce with rspec) which attributes are returned and (at least) their type?

To make a comparison, it would like having on the Github API orgs page not only one single example of the response:

[
  {
    "login": "github",
    "id": 1,
    "url": "https://api.github.com/orgs/github",
    "avatar_url": "https://github.com/images/error/octocat_happy.gif"
  }
]

but a documentation specifying that the organization object returned by the API always has:

  • login: string
  • id: integer
  • url: string
  • avatar_url: string

The documentation might then add some more value to these attributes, explaining in words what they are, and what their characteristics are (example: if they can be null, what is their maximum size, etc.).

What is your opinion on this?

Specify protocol to generate iodocs output

Hi,

now in iodocs output, the protocol is hardcoded to "http". I think that should be a configurable option but I'm not sure that it feels right for you. Any suggestions?

Issues with Hash serialization on tests with OAuth2MacClient: "excise webmock from the oauth client"

WebMock normalizes uri in a way, Rack can't parse correctly. But OAuth2MacClient relies on WebMock.

The limitation is: Hashes with digits as keys: {:digits => {'1' => 'One, '2' => 'Two'}}. In tests, they will be treated as {:digits => ['One', 'Two']}.

More information can be found here: #51

The case is:

WebMock::Util::URI.normalize_uri("e.com?a[]=b&a[]=c") 
#=> ...a%5B0%5D=b&a%5B1%5D=c <- it added 0 and 1

Rack::Utils.parse_nested_query("a%5B0%5D=b&a%5B1%5D=c") 
#=> {"a"=>{"0"=>"b", "1"=>"c"}} <- this is wrong: it must be {"a"=>["b", "c"]}

So, unfortunatly, I've added hack to remove digits, put by WebMock: denyago@69b6222#L1R57

DSL Redesign

Reference this issue for any PRs that affect the DSL.

Don't load FakeFS for all specs

The test suite is currently broken because ActiveSupport can't load a transliteration file to support the parameterize method, which is used in the iodocs formatter.

We need to figure out where FakeFS is needed, and include it more selectively. Alternatively, we can disable FakeFS around areas where the real file system is required, if possible.

json "route" parameter missing

Hey,

First of all, amazing project! Conceptually and well done too.

I am missing having the route parameter (e.g. it's used in mustache html_example.mustache) in the JSON files. I don't use the generated html files, so I need the json to have all those things so I can display it otherwise.

I used requests.first.request_path, but the problem with that one is that params like :id, :model_id are already replaced with IDs here, so it's not good.
While you're at it you could also add the http_method property, so it doesn't have to be guessed from requests.first.

Thanks and keep up the good work!

No way to describe response parameters

It is nice to have some way to describe response parameters, because now it is not full API documentation. Something like response_parameter :property_name, 'Property Name description'

Is there a way to document an API that works always with arrays?

I am following the http://jsonapi.org/ guidelines in a new api I'm creating. These guidelines enforce you to treat your resources always as arrays.

By example, if I want to create a Post object, even if its only a post, the POST request payload should look like this:

{
  posts: [
    { title: "Some fame war begin", content: "Loren ipsum...", author_id: 1 }
  ]
}

I could't figure out how to use de DSL to express that there is two parameters (title and content), that both are required, and they are nested inside an array.

Is there a way? Could this be acomplised with the new DSL?

Better documentation in the README

The README leaves a lot to be desired and could be better.

  • Better format of configuration options
  • Explain filters
  • Move DSL docs into README
  • Remove old and out of date documentation from wiki
  • Common examples

no_doc not working as expected?

We have a number of tests we would like to exclude from our generated documentation, but we can't seem to get the no_doc function (https://github.com/zipmark/rspec_api_documentation/wiki/DSL#no_doc) to work properly. We're still using 0.9.0 of the gem, but we tried upgrading to 1.0.0 just to see if it fixed it and it had no effect.

I created a simple example below of how we're trying to use it. When we run that spec through rake docs:generate, the result is API documentation for both tests, rather than just the first one. Is this functionality known to be broken, or are we perhaps just using it wrong?

https://gist.github.com/lazerwalker/6132709

Thanks!

Update to rspec 2.14

There is a warning being printed for deprecation of RSpec::Core::Configuration#backtrace_clean_patterns

DEPRECATION: RSpec::Core::Configuration#backtrace_clean_patterns is deprecated. 
Use RSpec::Core::Configuration#backtrace_exclusion_patterns instead. 
Called from lib/rspec_api_documentation/dsl.rb:17:in `<top (required)>'.

Change configurations from format-based to scope-based

The way configuration sets/configurations work right now doesn't make a whole lot of sense. Configurations define an output format, e.g. json, which is used to choose a mustache template.

The configurations should instead be based on a scope鈥攍ike public, private, vendor, client鈥攚hich would be used to generate different "collections" of documentation.

Formats should be selected per collection, allowing multiple.

Bump and publish new gem version

Last gem version does not include (at least) passing parameters as arrays. If this HEAD is stable enough, can we bump the version to 0.8.1 and publish to rubygems?

That way we won't need to point to a specific ref in my Gemfile.

Thanks!

@hiremaga & @hjhart

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    馃枛 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 馃搳馃搱馃帀

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google 鉂わ笍 Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.