Giter Site home page Giter Site logo

apidoc-spec's Introduction

Important note

This project is currently not active maintained! See discussion #1436

apiDoc

apiDoc creates a documentation from API descriptions in your source code.

validate NPM version Join the chat at https://gitter.im/apidoc/talk

Documentation: apidocjs.com

Installation

$ npm install -g apidoc

Usage

Add some apidoc comments anywhere in your source code:

/**
 * @api {get} /user/:id Request User information
 * @apiName GetUser
 * @apiGroup User
 *
 * @apiParam {Number} id User's unique ID.
 *
 * @apiSuccess {String} firstname Firstname of the User.
 * @apiSuccess {String} lastname  Lastname of the User.
 */

Now generate the documentation from src/ into doc/.

$ apidoc -i src/ -o doc/

This repository contains and example folder from which you can generate a very complete documentation on an example api endpoint. It also contains best practice hints (in the footer.md file).

$ git clone https://github.com/apidoc/apidoc && cd apidoc
$ npm install --prod
$ ./bin/apidoc -i example -o /tmp/doc
$ $BROWSER /tmp/doc

Programmatic usage

You can generate the documentation programmatically:

import path from 'path'
import { createDoc } from 'apidoc'

const doc = createDoc({
  src: path.resolve(__dirname, 'src'),
  dest: path.resolve(__dirname, 'doc'), // can be omitted if dryRun is true
  // if you don't want to generate the output files:
  dryRun: true,
  // if you don't want to see any log output:
  silent: true,
})

if (typeof doc !== 'boolean') {
  // Documentation was generated!
  console.log(doc.data) // the parsed api documentation object
  console.log(doc.project) // the project information
}

Install type definitions (see @types/apidoc):

$ npm install -D @types/apidoc

Docker image

You can use apidoc in Docker like this:

# first build the image after cloning this repository
docker build -t apidoc/apidoc .
# run it
docker run --rm -v $(pwd):/home/node/apidoc apidoc/apidoc -o outputdir -i inputdir

Supported programming languages

  • C#, Go, Dart, Java, JavaScript, PHP, Scala (all DocStyle capable languages):

    /**
      * This is a comment.
      */
  • Clojure:

    ;;;;
    ;; This is a comment.
    ;;;;
  • CoffeeScript:

    ###
    This is a comment.
    ###
  • Elixir:

    #{
    # This is a comment.
    #}
  • Erlang:

    %{
    % This is a comment.
    %}
  • Perl

    #**
    # This is a comment.
    #*
    =pod
    This is a comment.
    =cut
  • Python

    """
    This is a comment.
    """
  • Ruby

    =begin
    This is a comment.
    =end

Plugins (extend apiDoc)

apiDoc will auto include installed plugins.

  • apidoc-plugin-schema Generates and inject apidoc elements from api schemas. npm install apidoc-plugin-schema

For details and an example on how to implement your own plugin, please view apidoc-plugin-test.

Support

Please create a new issue if you have a suggestion/question or if you found a problem/bug.

Contributing

apiDoc is a collaborative project. Pull requests are welcome. Please see the CONTRIBUTING file.

Build tools

Integration

Converter

apidoc-spec's People

Contributors

rottmann avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

apidoc-spec's Issues

Suggestion for versioning

I hope it is the correct place to ask
So I have a suggestion to make versioning easier:
What if you add a command to copy all current apiDoc blocks to a file the will keep all history and then you update all those block to a newer version (as the one mentioned in apidoc.json)?
You could also add an apiDoc parameter named @apiOriginal to mark blocks as the updated ones, all unoriginal blocks won't be copied to the history file.
The specs might need improvement but if it sounds good I'm willing to try and make a PR with this feature.

Remove markup from generated JSON

I noticed that in the generated JSON output, there are p tags in sections like description and type, etc. Example:

{
    "type": "get",
    "url": "/assembly/definition/:did/workspace/:wid/element/:eid",
    "title": "Assembly Definition",
    "name": "GetAssemblyDefinition",
    "description": "<p>Get definition of requested assembly</p> ",
    "group": "Model",
    "version": "0.1.0",
    "permission": [
      {
        "name": "auth",
        "title": "Authenticated access only",
        "description": "<p>Must be logged in to access this resource.</p> "
      }
    ]
}

These are simple to get rid of on the front end that I'm feeding the JSON to, but I think it'd be best to not have them be there in the first place, to separate data from markup. Thoughts? I understand the appeal of support for links in the comments, but feel as though a clean, HTML-free JSON file would be best for most people. Perhaps a new @apilink annotation could help keep the link support

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.