GithubHelp home page GithubHelp logo

iodocs's Introduction

I/O Docs Community Edition in Node.js

Copyright 2011-2014 Mashery, Inc.

http://www.mashery.com

http://developer.mashery.com

MAJOR CHANGE LOG

2014-07-22 - Summer Release Feature Enhancements

This set of updates addresses several feature requests around POST/PUT calls. There are several other enhancements listed below. Note, if you are using a version of I/O Docs Community Edition that pre-dates this release, you will need to update your schema. The structure is similar in many ways, but the top level objects have been renamed, as well as many of the key names.

  • Numerous schema changes and improvements
    • Support for references
    • Base paths and authorization moved from apiConfig to api{name}.json files
    • More robust/extensible auth definition block
  • POST/PUT request body capabilities added
    • Array type and interface added for use in request body
    • Size and order support
    • Serialized JSON support
  • Parameter location enhancements
    • Placement in the query string, path or header
  • Method form UI generation driven by Alpaca/jQuery

SYNOPSIS

I/O Docs is a live interactive documentation system for RESTful web APIs. By defining APIs at the resource, method and parameter levels in a JSON schema, I/O Docs will generate a JavaScript client interface. API calls can be executed from this interface, which are then proxied through the I/O Docs server with payload data cleanly formatted (pretty-printed if JSON or XML). Basic HTML text tags are enabled in the JSON schema.

You can find the latest version here: https://github.com/mashery/iodocs

However, we recommend that you install I/O Docs with npm, the Node package manager. See instructions below.

BUILD/RUNTIME DEPENDENCIES

  1. Node.js - server-side JS engine
  2. npm - node package manager
  3. Redis - key+value storage engine

Build note: If you're not using a package manager, Node and some of the modules require compiler (like gcc). If you are on a Mac, you will need to install XCode. If you're on Linux, you'll need to install build-essentials, or something equivalent.

Redis note: Redis is considered a runtime dependency. It is used to store OAuth information server side. If you are not implementing OAuth, redis is not required. You can simply remove the redis block from config.json. However, if you do implement OAuth down the road, you will need to use Redis, otherwise you will see 500 errors during the auth dance.

INSTALLATION INSTRUCTIONS FOR NODE, NPM & REDIS

  1. Node.js - https://github.com/joyent/node/wiki/Installation
  2. npm (Node package manager) - https://github.com/isaacs/npm
  3. Redis - http://redis.io/download

INSTALLATION INSTRUCTIONS FOR I/O DOCS

From the command line type in:

  git clone http://github.com/mashery/iodocs.git
  cd iodocs
  npm install

Node Module Dependencies

These will be automatically installed when you use any of the above npm installation methods above.

  1. express - framework
  2. oauth - oauth library
  3. redis - connector to Redis
  4. connect-redis - Redis session store
  5. querystring - used to parse query string
  6. jade - the view engine
  7. supervisor - restart node upon an error or changed javascript file

Note: hashlib is no longer a required module -- we're using the internal crypto module for signatures and digests.

RUNNING I/O DOCS

Create your config file by copying the default config:

cp config.json.sample config.json

The defaults will work, but feel free to change them.

Run a Redis instance:

redis-server

Start I/O Docs:

npm start (*nix, Mac OSX)
npm run-script startwin (Windows)

Start I/O Docs with a custom config file:

./node_modules/.bin/supervisor -e 'js|json' -- app --config-file ../config.json (*nix, Mac OSX)
supervisor -e 'js' -- app --config-file ../config.json (Windows)

Ideally, the --config-file arg would be possible to use with npm start, but until npm issue #3494 is resolved, this is not supported.

Point your browser to: localhost:3000

CONFIGURING API DEFINITION LOCATION

API definitions are, by default, stored in ./public/data/ and described by ./public/data/"apiName".json and referenced by ./public/data/apiconfig.json. This can be overridden in config.json by setting the "apiConfigDir" property.

BASIC AUTH FOR SERVER

Enabling HTTP basic authentication on the server is simple. By default, the username and password values are empty ("").

  1. Open up config.json
  2. Navigate down to the basicAuth object
  3. Add values for username and password within the object

QUICK API CONFIGURATION EXAMPLE

Adding an API to the I/O Docs configuration is relatively simple.

First, append the api name to the ./public/data/apiconfig.json file.

Example:

"lowercaseapi": {
    "name": "Lower Case API"
}

Add the file ./public/data/lowercaseapi.json to define the API.

Example:

{
    "name": "Lower Case API",
    "description": "An example api.",
    "protocol": "rest",
    "basePath": "http://api.lowercase.sample.com",
    "publicPath": "/v1",
    "auth": {
        "key": {
            "param": "key"
        }
    },
    "headers": {
        "Accept": "application/json",
        "Foo": "bar"
    },
    "resources": {
        "Resource Group A": {
            "methods": {
                "MethodA1": {
                    "name": "Method A1",
                    "path": "/a1/grab",
                    "httpMethod": "GET",
                    "description": "Grabs information from the A1 data set.",
                    "parameters": {
                        "param1": {
                            "type": "string",
                            "required": true,
                            "default": "",
                            "description": "Description of the first parameter."
                        }
                    }
                },
                "MethodA1User": {
                    "name": "Method A1 User",
                    "path": "/a1/grab/{userId}",
                    "httpMethod": "GET",
                    "description": "Grabs information from the A1 data set for a specific user",
                    "parameters": {
                        "param1": {
                            "type": "string",
                            "required": true,
                            "default": "",
                            "description": "Description of the first parameter."
                        },
                        "userId": {
                            "type": "string",
                            "required": true,
                            "default": "",
                            "description": "The userId parameter that is in the URI."
                        }
                    }
                }
            }
        }
    }
}

By default the parameters are added to the query string. But if the URI contains a named variable, it will substitute the value in the path.

TOP-LEVEL SERVICE CONFIG DETAILS

The apiconfig.json file contains the name of an API to show upon initiation.

"lowercaseapi": {
        "name": "Lower Case API"
}

The high-level information about an API is set in the config JSON file.

Example #1 - Explanation of each field in an example API config that uses basic key authentication:

{
    "name": "Lower Case API",
    "protocol": "rest",
    "basePath": "http://api.lowercase.sample.com",
    "publicPath": "/v1",
    "auth": {
        "key": {
            "param": "key",
            "location": "query"
        }
    },
    "headers": {
        "Accept": "application/json",
        "Foo": "bar"
    },
    ...

Line:

(1). "name" key value is a string that holds the name of the API that is used in the Jade template output. Also true in apiconfig.json.

(2). "protocol" key value is either rest or soap

(3). "basePath" key value is the host path of the API calls

(4). "publicPath" key value is the full path prefix prepended to all method URIs. This value often includes the version in RESTful APIs.

Ex: "/v1"

In the Example #3 below, there is also "privatePath"
which is used for endpoints behind protected resources.

(5). "auth" container holds the authorization information. If absent, API requires no authorization.

(6). The key value that describes the auth method. Valid values can be: "key" - simple API key in the URI "oauth" - OAuth 1.0/2.0 "" - no authentication

(7). "param" key value is name of the parameter that is added to an API request when the "auth" key value from (6) is set to "key".

(8). "location" (optional) key value sets where the api key will go in the request. Defaults to "query". supported values: "query" and "header".

(9). "headers" object contains key value pairs of HTTP headers that will be sent for each request for API. These are static key/value pairs.


Example #2 - Explanation of each field in an example API config that uses basic key authentication with signatures (signed call).

{
    "name": "Lower Case API",
    "protocol": "rest",
    "basePath": "http://api.lowercase.sample.com",
    "publicPath": "/v1",
    "auth": {
        "key": {
            "param": "key",
            "signature": {
                "type": "signed_md5",
                "param": "sig",
                "digest": "hex",
                "location": "header"
            }
        }
    },
    ...

Line:

(1). "name" key value is a string that holds the name of the API that is used in the Jade template output. Also true in apiconfig.json.

(2). "protocol" key value is either rest or soap

(3). "basePath" key value is the host path of the API calls

(4). "publicPath" key value is the full path prefix prepended to all method URIs. This value often includes the version in RESTful APIs.

Ex: "/v1"

In the Example #3 below, there is also "privatePath"
which is used for endpoints behind protected resources.

(5). "auth" container holds the authorization information. If absent, API requires no authorization.

(6). The key value that describes the auth method. Valid values can be: "key" - simple API key in the URI "oauth" - OAuth 1.0/2.0

(7). "param" key value is name of the parameter that is added to an API request when the "auth" key value from (6) is set to "key".

(8). "signature" is a JSON object that contains the details about the API call signing requirements. The signature routine coded in app.js is a hash of the string concatenation of API key, API key secret and timestamp (epoch).

(9). "type" key value is either signed_md5 or signed_sha256. More signature methods are available with crypto.js, but have not been included in the code as options.

(10). "param" key value is the name of the parameter that is added to an API request that holds the digital signature.

(11). "digest" key value is the digest algorithm that is used. Values can be hex, base64 or binary.

(12). "location" (optional) key value sets where the signature will go in the request. Defaults to "header".


Example #3 - Foursquare API config that uses 3-legged OAuth 2.0

{
    "name": "Foursquare (OAuth 2.0 Auth Code)",
    "protocol": "rest",
    "basePath": "https://api.foursquare.com",
    "privatePath": "/v2",
    "auth": {
        "oauth": {
            "version": "2.0",
            "type": "authorization-code",
            "base_uri": "https://foursquare.com/",
            "authorize_uri": "oauth2/authenticate",
            "access_token_uri": "oauth2/access_token_uri",
            "token": {
                "param": "oauth_token",
                "location": "query"
            }
        }
    },
    ...

Line:

  1. "name" key value is a string that holds the name of the API that is used in the Jade template output. Also true in apiconfig.json.

  2. "protocol" key value is either rest or soap

  3. "basePath" key value is the host path of the API calls

  4. "privatePath" key value is the path prefix prepended to all method URIs for OAuth protected method resources. This value is most often the version in RESTful APIs.

    Ex: "/v1", "/1", etc.

  5. "auth" container holds the authorization information. If absent, API requires no authorization.

  6. "oauth" key value is a JSON object that contains the OAuth implementation details for this API.

  7. "version" key value is the OAuth version. OAuth 1.0 and 2.0 supported.

  8. "type" key value is the OAuth 2 authorization flow used for this API. Valid values are "authorization-code", "client_credentials", and "implicit", named for each grant found here: "http://tools.ietf.org/html/rfc6749".

  9. "base_uri" key value is the base website URL used in the OAuth 2 dance. It is required.

  10. "authorize_uri" key value is the url string used to retrieve the authorization token in the "authorization-code" OAuth 2 flow. This is not necessary in any other OAuth 2 flow.

  11. "access_token_uri" key value is the url string used to retrieve the access (Bearer) token in any OAuth 2 flow. This is required in all OAuth 2 flows.

  12. "token" container instructs I/O Docs where to use the access/bearer token on requests. If the "location" is set as the default token name when making calls with the access token in the url query parameters. Not required if "access_token" is used.

  13. "param" is the parameter name for access token. This is valid only if the location value is "query"

  14. "location" (optional) key value that sets where the bearer token will go. Acceptable values are: "header" and "query". If set to header, I/O Docs will follow the "Authorization: Bearer XXX" pattern. If set to "query", the name of the key will be dictated by the "param" value on line 13.

Additional Note: All redirect URIs for the Foursquare API & your Foursqare app must be set through the Foursquare developer site. For the iodocs Foursquare API test these URIs are : "http://localhost:3000/foursquare", "http://localhost:3000/oauth2Success/foursquare"

For the Rdio API test, beta access to their new API is necessary. The site for the beta API is: "http://www.rdio.com/developers/"

API-LEVEL CONFIG DETAILS

For every API that is configured in apiconfig.json a JSON config file must exist. You should look at the ./public/data/ directory for examples.

Example #1 - Explanation of each field in an example API-level configuration

{
    "name": "Lower Case API",
    "protocol": "rest",
    "basePath": "http://api.lowercase.sample.com",
    "resources": {
        "User Resources": {
            "methods": {
                "showUsers": {
                    "name": "users/show",
                    "description": "Returns extended user information",
                    "httpMethod": "GET",
                    "path": "/users/show.json",
                    "parameters": {
                        "user_id": {
                            "title":"user_id",
                            "required":true,
                            "default":"",
                            "type":"string",
                            "description":"The ID of the user"
                        },
                        "cereal": {
                            "title": "cereal",
                            "required": true,
                            "default": "fruitscoops",
                            "type": "string",
                            "enum": ["fruitscoops","sugarbombs","frostedteeth"],
                            "description": "The type of cereal desired."
                        },
                        "skip_status": {
                            "title": "skip_status",
                            "required": false,
                            "default": "false",
                            "type":"boolean",
                            "description":"If true, status not included."
                            "location": "header"
                        },
                        "include_status": {
                            "title": "include_status",
                            "required": false,
                            "default": false,
                            "type": "boolean",
                            "description": "If true, status included."
                            "booleanValues": ["yes","no"]
                        },
                        "review": {
                            "title": "review",
                            "required": false,
                            "default": "",
                            "type": "textarea",
                            "description": "The user's review to submit."
                        }
                    }
                }
            }
        }
    }

Line:

(1). "name" key value is a string that holds the name of the API that is used in the Jade template output. Also true in apiconfig.json.

(2). "protocol" key value is either rest or soap

(3). "basePath" key value is the host path of the API calls

(4). "resources" JSON container. Methods are grouped into resources.

(5). The first resource.

(6). "methods" key value is an array of JSON objects (each one being a method)

(7). The first method.

(8). "name" key value is a string that is displayed via the view template. The name of the method.

(9). "description" key value is a short description of the method.

(10). "httpMethod" key value can be either GET, POST, DELETE or PUT (all caps)

(11). "path" key value is the path to the method that is appended to the baseURL and the public/private path.

(12). "parameters" key value is a JSON objects containing the parameters

(13). The first parameter.

(14). "title" key value is a string that contains the name of the parameter.

(15). "required" key value is either true or false.

(16). "default" key value is a string, containing a default value that will be automatically populated onto the form.

(17). "type" key value can be an arbitrary string that describes the variable type; however, the value is boolean or enumerated a drop-down (select) box will appear.

(18). "description" key value is a string, containing the description of the parameter.

(25). "enum" key value is an array of enumerated values that will render a drop-down (select box) on the form.

(32). "type" key value is boolean that will render a drop-down (select box) on the form for true and false.

(24). "location" (optional) key value determines where the parameter will go. Can be "query" or "header". Default to "query".

(43). "booleanValues" is an array of [true, false] alternatives that will instead populate the drop down box.

(49). "type" key value is textarea that will render a textarea box, a multi-line text input control.

Example #2 - Request Bodies, Arrays, & Objects

{
    "name": "Lower Case API",
    "protocol": "rest",
    "basePath": "http://api.lowercase.sample.com",
    "schemas": {
        "showUsers": {
            "properties": {
                "bodyParam": {
                    "title":"bodyParam",
                    "required":true,
                    "default":"",
                    "type":"string",
                    "description":"An example parameter in the body"
                },
                "arrayExample": {
                    "type": "array",
                    "items": {
                        "title":"arrayExample",
                        "required": true,
                        "default": "foobar",
                        "type":"string",
                        "description":"An array in the body."
                    }
                },
                "objectExample": {
                    "type": "object",
                    "properties": {
                        "element1": {
                            "title": "element1",
                            "required":false,
                            "type":"string",
                            "description": "An element in a JSON object.",
                            "default": "el1"
                        },
                        "element2": {
                            "title": "element2",
                            "required":false,
                            "type":"string",
                            "description": "Second element in a JSON object.",
                            "default": "el2"
                        },
                        "subObjectEx": {
                            "type": "object",
                            "properties": {
                                "element3": {
                                    "title": "element3",
                                    "required":false,
                                    "type":"string",
                                    "description": "An element within an object within an object.",
                                    "default": "el3"
                                }
                            }
                        }
                    }
                }
            }
        }
    },
    "resources": {
        "User Resources": {
            "methods": {
                "showUsers": {
                    "name": "users/show",
                    "description": "Returns extended user information",
                    "httpMethod": "GET",
                    "path": "/users/show.json",
                    "request": {
                        "$ref": "showUsers"
                    },
                    "parameters": {
                        "user_id": {
                            "title":"user_id",
                            "required":true,
                            "default":"",
                            "type":"string",
                            "description":"The ID of the user"
                        }
                    }
                }
            }
        }
    }

Line:

(4). "schemas" JSON object. Contains the parameters that will go into the request body for all methods.

(5). The first method to contain a request body.

(6). "properties" JSON object containing the parameters that will go into the request body.

(7). The first request body parameter. The format is the same as in "resources"

(14). An array parameter. An array parameter can add as many values to the parameter as necessary. The default location for an array will always be "body".

(15). "type" key value set to array. Necessary for the array functionality to work.

(16). "items" JSON object that contains the parameter information. Format is consistent from resources parameters.

(24). A JSON object parameter.

(25). "type" key value set to object. Necessary for the object functionality to work.

(26). "properties" JSON object containing the parameters that will go into the object.

(41). An object embedded within an object.

(66). "request" JSON object holds the reference to the request body parameters

(67). "$ref" key value is the reference to the same string in "schemas"

SUPPORT

If you need any help with I/O Docs, you can reach out to us via the GitHub Issues page at: http://github.com/mashery/iodocs/issues

iodocs's People

Contributors

adamkaplan avatar aleksi avatar alexadkins avatar goliatone avatar hillct avatar jedwood avatar jplock avatar kamalgill avatar kevinpeterson avatar kmiyashiro avatar krisrak avatar lornajane avatar mansilladev avatar marceloemmerich avatar martintajur avatar mtougeron avatar nathanwdavis avatar nortron avatar phairow avatar precision avatar rmax avatar rowanhill avatar sco11morgan avatar silentdth avatar sqmk avatar stackus avatar switzer avatar synedra avatar vky avatar zhendershot 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  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

iodocs's Issues

Clarification of baseURL and publicPath settings in apiconfig.json

Does the baseURL require a host name rather than a URL prefix?

Downloaded I/O Docs on August 10, 2011 from GitHub and noticed the apiconfig.json settings for baseURL expects a host name (e.g. example.com) rather than a URL prefix (e.g. http://example.com/api), with the publicPath expected to be the full relative path to the api (eg. /sampleAPI/v1) rather than a simple version identifier.

To clarify, if the API URL is at 'http://example.com/sampleAPI/v1', the baseURL appears to expect 'example.com' while the the publicPath should be '/sampleAPI/v1'.

json/xml request bodies

Currently working with some REST based services. Was pointed at IODocs as a documentation mechanism for them (and think it is a fabulous tool)

Ran into issues trying to:

support the use of multiple request headers for content negotiation
handle xml or json as the service request body.

After exploring and borrowing liberally from the options presented here, tried out the following changes locally to support simple xml or json, and the setting of (at least) Accept and Content-Type headers.

Would welcome suggestions for doing this better.

patch with local changes

https://gist.github.com/3925249

Node.js init script

About the Node.js library init script for iodocs? correct me if i am wrong but I think that relative paths on the app.js will bring problems when we make init scripts. I am actually using https://gist.github.com/715255 but it fails because of the path in app.js

File input support

Hi all,

Just wanted to say great job on this so far, support for file inputs would be quite helpful!

Enumerated Paramater as Header

With adding "Location":"header" we can add now a parameter to the header of a request.

That is very cool feature, but unfortunately it does not work ifthe parameter is of type:"enumerated".

eg:

"parameters":[{
                     "Name":"Accept",
                     "Required":"Y",
                     "Default":"application/json",
                     "Type":"enumerated",
                     "EnumeratedList": [
                        "application/json",
                        "application/xml"
                        ],
                     "Description":"DD",
                     "Location":"header"

                  }]

In this case, the parameter will be still added to the URI

How to run GET,POST,PUT and DELETE service

Hello. I am not able to run any service in iodocs.when i run post service, i am getting following error

HTTP Status 400 - org.codehaus.jackson.JsonParseException: Unexpected character ('a' (code 97)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
at [Source: org.apache.catalina.connector.CoyoteInputStream@2802690b; line: 1, column: 2]

Kindly suggest the solution

Setting different database on Redis

Hi everyone,
I've encountered some difficulties on trying to set a different db on Redis (we're using Redis on our project, so we wanted to avoid to use the same db for different things.

I thought that the database configuration in config.json would work but that's not true (that parameter is not used) so I explored the code and setted manually (after a bit of research).

So, if you want the database in config.json to work you've to add this (line 99) during the creation of the redis-store:

store:  new RedisStore({
            'host':   config.redis.host,
            'port':   config.redis.port,
            'pass':   config.redis.password,
            'db':     config.redis.database,
            'maxAge': 1209600000
        })

I don't know if this is an issue but maybe is going to save time to someone else. : )

Add support for configurable method URIs

I have a scenario where I'd like to have the last part of my method URIs be enterable in the form just like the query parameters are. Does anyone else need this sort of thing? The reason is that the last part of the URI is an ID value that would vary for each end user.
I was wondering if there has been any discussion of using a special syntax for part of the URI so that it would automatically be added to the form and before the request is submitted the value entered in the form will be added to the actual URI of the request.

HTTP POST/PUT params

Is there any way parameters can be passed in the request body rather than the url for POST/PUT methods? Currently all params are sent via the url, even for POST/PUT.

Express 3 compatibility

I just made the necessary changes in my local modified version. If nobody else is already working on this, I'd be glad to submit a pull request.

installing iodocs with node v0.8.2

(disclaimer: I'm quite a newbie at node, my experience is in other scripting languages)

I am trying to install iodocs on my ubuntu machine. Running npm install makes express give errors about my node version:

npm ERR! Unsupported
npm ERR! Not compatible with your version of node/npm: [email protected]
npm ERR! Required: {"node":">= 0.4.1 < 0.7.0"}
npm ERR! Actual: {"npm":"1.1.16","node":"0.8.2"}
npm ERR!
npm ERR! System Linux 3.0.0-21-generic
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install"
npm ERR! cwd /home/lorna/svndir/iodocs/lornajane
npm ERR! node -v v0.8.2
npm ERR! npm -v 1.1.16
npm ERR! code ENOTSUP
npm ERR! message Unsupported
npm ERR! errno {}

I installed the current express version, but that's v3.0.0rc4 and that made things worse. I found this stackoverflow question helpful: http://stackoverflow.com/questions/9577988/install-iodocs-on-linux but I'm not any further forward.

What versions of node/express can I use? RTFM links and other pointers are all gratefully received - I have a REST API that I think would be a great use of iodocs if I could only get this going :)

replacing URI placeholders

I see the code is replacing placeholders marked with a colon preceding the parameter name, like :paramName . But there's something that I think is not right - placeholders for parameters (even optional ones) with no supplied value (which ==="") are not replaced. I'm going to get that fixed (because I need it ;-) ) but thought to post this in case someone's got good arguments against.

Cheers

Content-Length not updated between request

It seems the Content Length for requests are set to the same value between requests. This makes requests fail when sending subsequent requests with more data if the server respects the Content-Length since the input will be truncated.

Example

First request

POST / HTTP/1.1
Content-Length: 12
Content-Type: application/x-www-form-urlencoded
Host: localhost:3001
Connection: keep-alive

param=short

Second request

POST / HTTP/1.1
Content-Length: 12        <=== Still 12! Should be 14 since param is now longer
Content-Type: application/x-www-form-urlencoded
Host: localhost:3001
Connection: keep-alive

param=longer

support non-standard http verbs

It might be an odd choice, but some REST APIS might use other verbs than post/put/get/delete. It would be nice if these were supported in the generated docs/forms

Password Protect the iodocs page

Hi Guys,

is there a way to add basic authorization to iodocs app? So it asks for pre-defined login and password before opening the list of APIs?

thanks,
Dmitry

Support for nested parameter names

Hello,

It seems that iodocs uses "querystring", which decided to not support nested parameter keys (i.e. deep objects) in 0.3:
https://github.com/joyent/node/wiki/Migrating-from-v0.2-to-v0.3

This means that Rails-style parameter names are no longer supported. i.e.:

In iodocs, that would be configured something like this:


A fix is to require('qs') instead of require('querystring'), which re-introduces support for deep objects. The "node-querystring" project can be found here:
https://github.com/visionmedia/node-querystring

If others would also find this valuable, perhaps support for nested objects could be introduced in iodocs.

Thanks!
Adam

https?

Howdy, my api is running on https, I pass this in as the protocol and nada: broken. I go into the code and as far as a I can tell you're only including 'http' with no condition on the protocol to include 'https'. I add this and it works great, but I wonder if I'm missing something as I am not a node.js expert by an means. Thanks!

This request requires HTTP authentication

When i send a get request in my own application its showing 401 error . Response body is like below :

<title>Apache Tomcat/6.0.16 - Error report</title> <style> </style>

HTTP Status 401 -


type Status report

message

description This request requires HTTP authentication ().


Apache Tomcat/6.0.16

Support to handle different content type in Payload (Text,JSON etc.) according to “Content-Type” header

Hi,

I get error when I run “POST” request with “Content-Type”: “application/json”, as payload always goes as text. There must be check to handle different content-type, below is code which I changed to get it working.

Line number 341 in app.js
From:
if (['POST','DELETE','PUT'].indexOf(httpMethod) !== -1) {
var requestBody = query.stringify(params);
}

To:
if (['POST','DELETE','PUT'].indexOf(httpMethod) !== -1) {
var requestBody = JSON.stringify(params);
}

Thanks,
Shailesh

Deprecation warnings in Webkit browsers

The following deprecation warnings are visible in the console for Chrome, Safari, etc. The message sounds a bit on the urgent side.

event.layerX and event.layerY are broken and deprecated in WebKit. They will be removed from the engine in the near future.

Cannot read property 'Content-Length' of undefined

TypeError: Cannot read property 'Content-Length' of undefined
at unsecuredCall (/Projects/iodocs/app.js:519:29)
at processRequest (
/Projects/iodocs/app.js:462:9)
at callbacks (/Projects/iodocs/node_modules/express/lib/router/index.js:272:11)
at oauth (
/Projects/iodocs/app.js:185:9)
at callbacks (/Projects/iodocs/node_modules/express/lib/router/index.js:272:11)
at param (
/Projects/iodocs/node_modules/express/lib/router/index.js:246:11)
at pass (/Projects/iodocs/node_modules/express/lib/router/index.js:253:5)
at Router._dispatch (
/Projects/iodocs/node_modules/express/lib/router/index.js:280:5)
at Object.middleware as handle
at next (~/Projects/iodocs/node_modules/express/node_modules/connect/lib/http.js:204:15)
127.0.0.1 - - [Mon, 29 Oct 2012 13:03:59 GMT] "POST /processReq HTTP/1.1" 500 - "http://localhost:3000/osstudio" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4"

config.address is not used ?

hi, imho there is a problem with the app.listen at the end of app.js : the config.address is not used !?

app.listen(port);

But if I write this :

app.listen( port , config.address );

then there is an error with the console.log :

TypeError: Cannot read property 'port' of null

( If I comment out the console.log line , the server starts well on the specified address )

OAuth Post - parameters not in the body

Some I just started messing around with this and was able to get my OAuth 1.0a testing going pretty easily. GET requests gave me zero problems, however when I started trying to do POST requests, I found that it was sending a POST, but it had the parameters in the URL.

OAuth Type: Three-legged
OAuth Module - version 0.9.8

In app.js, I found that for 3-legged, it is still using "getProtectedResource" from the Oauth module, which is listed as deprecated. Would it simply need to make a call similar to the two-legged method of using the switch-case to call the individual methods?

Thanks

Add support for file upload

Since some APIs use file uploads and IO docs will output a text box it would be nice to have support to upload a file through IO docs to test the API.

Avoid absolute links to resources

All links to /images, /javascripts, /stylesheets, and api requests (at least processReq) are currently started with / symbol which prevents to locate iodocs service under subfolder.

Thus http://*****.com/iodoc with the following nginx snippet doesn't work due to this limitation

 location /iodoc {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        rewrite /iodoc/(.*) /$1 break;
        proxy_pass http://localhost:3000/;
        proxy_redirect off;
   }

OAuth Three-legged with multiple API

If I add more than one API to apiconfig.json with the same type of auth (oauth three-legged) I only can log in in one API because the other one appears like I am already logged in.

Is it a known issue or I am doing some wrong?

multipart boundary supprt

I am trying to get iodocs to POST a message to my REST service that expects a "multipart/form-data" content-type. How do I persuade iodocs to put in bundaries on POST? When I snoop the message being sent I can see there are no boundaries and I get the following error on the server side:

java.lang.RuntimeException: org.apache.cxf.interceptor.Fault: Couldn't find MIME boundary: --myboundary

My iodocs config is:

"OSSUI": {
"name": "Personal Storage",
"protocol": "http",
"baseURL": "jrbuild1srv:28080",
"publicPath": "/ossui-examples/services/rest/ossui/preferences",
"headers" : {"Content-Type": "multipart/form-data; boundary=myboundary"},
"auth": "",
"keyParam": ""
}

{
"endpoints":[
{
"name":"Save Methods",
"methods":[
{
"MethodName":"Save preferences",
"Synopsis":"This method allows you to save a string in personal storage",
"HTTPMethod":"POST",
"URI":"/set",
"RequiresOAuth":"N",
"parameters":[
{
"Name":"name",
"Required":"Y",
"Default":"Test",
"Type":"string",
"Description":"Authorized user name"
},
{
"Name":"value",
"Required":"Y",
"Default":"",
"Type":"string",
"Description":"Value to store"
}
]
}
]
},
{
"name":"Fetch Methods",
"methods":[
{
"MethodName":"Fetch preferences",
"Synopsis":"This method allows you to fetch a string from personal storage",
"HTTPMethod":"GET",
"URI":"/get",
"RequiresOAuth":"N",
"parameters":[
{
"Name":"name",
"Required":"Y",
"Default":"Test",
"Type":"string",
"Description":"Authorized user name"
}
]
}
]
}
]
}

Two-legged authentication

Hello,

Although it's mentioned briefly in the documentation I can't seem to find much information regarding two-legged authentication support within IO Docs.

am I missing something quite obvious?

Thanks,
Matt.

Add support for enumerated values from a URL

Hi! I am really liking iodocs - thanks for opening it to everyone.

I like the 'enumerated' data type for lists of values - however, this list goes stale if the values are a dictionary that is constantly updated. For example, I would like to be able to provide a dictionary value as follows:

"parameters":[
  {
    "Name":"timezone",
    "Required":"Y",
    "Default":"America/New_York",
    "Type":"enumerated",
    "EnumeratedURL":"http://api.jirafe.com/timezones"
    "Description":"The time zone that this site uses for order dates"
  }
]

The URL passed in can be a list of values separated by a CR by default (the URL in my example works).

non-query string parameters

Hi guys, I like the support for placement of parameters within the URI but before the query string, like so: "/api/test/get/:param1". Thanks for that as well!

The only issue I find with this is that if :param1 is defined as an optional parameter then the resulting URI will still contain the text ":param1" when the value for :param1 is empty. If :param1 is set to a value before the request is made, the URI is updated correctly to send that value; it's only when empty that the expected behavior or ":param1" being removed from the URI doesn't happen.

Running iodocs behind an http proxy

We are trying to setup iodocs on our internal network behind an http proxy and call our web apis in the cloud over https.
We could not find a way to get around this, even by using Charles, MacProxy.
Is there any support planned in iodocs for proxy settings? or some wiki help to setup a proxy that will work with iodocs?

Thanks,
Florin

OAuth 2.0 support

Is there any current plan to implement support for OAuth 2.0, I'm looking forward to using IO Docs on some of my future projects.

Introspection of REST URL

I think I/O Docs is fantastic. I was wondering if anybody has considered a REST URL introspector that would generate a barebones .json config file.
Thanks for the great work on I/O Docs!

Break Out Parameter Types?

My company's API has multiple parameter types. We have required (already a flag for that in IODocs) as well as optional, filter, group, etc. parameters.

I've been just adding the parameter type in the description, but it's still hard to see the different groupings. Is there a way to break out the different types of parameters to make it easier to digest?

Johnny

Update jQuery to 1.9.x

jQuery is a bit out of date with this implementation. Suggesting that we update to 1.9.x, and update the UI to make use of any new stuff.

Send data json encoded format

hi,
i want send tha data by post method. but i want send data in json encoded format how can i send the data.

Thanks

Documentation is missing desciption of custom header usage

I am evaluating iodocs as a REST documentation tool and I found it quite nice how fast I got a first example running. Unfortunately now I'm struggling with a thing that I couldn't find in any of the readme files: we use certain request headers with our services that I'd like to be present in iodocs. My first idea was to put a section called "headers" in the json description files and insert the required entries, but that only changed the html page to show an expandable headers section with no prefilled entry.

Is there a way to define custom headers and if so: how is the exact syntax in the json file?

I found an example on http://developer.mashery.com/iodocs# that had this feature by setting a "fixed" parameter (Aetna Retail Rx Pricing API).

Can a user select whether or not to pass variables?

When using IODocs as an API explorer, I would like to decide whether or not to pass a variable at all. For example, if I want to have an endpoint that lists users, I would like to be able to have a querystring variable that, if present, either filters users that are active or inactive. So, the following URL's would return the following:

http://api.example.com/v1/users - return a list of all users
http://api.example.com/v1/users?active=true - return a list of active users only
http://api.example.com/v1/users?active=false - return a list of inactive users only

Is there a way to define my API in IODocs so that I can use the API to construct all three URL's (including the first one which I cannot find a way to do if I create an 'active' querystring variable).

Perhaps one UI technique would be to have an 'x' all the way right which appears on mouseover, and if you click the 'x', the box is grey'ed out.

Thanks!

NPM install issue

npm install
npm WARN [email protected] package.json: bugs['web'] should probably be bugs['url']
npm ERR! Unsupported
npm ERR! Not compatible with your version of node/npm: [email protected]
npm ERR! Required: {"node":"0.4.x","teleport":">=0.2.0"}
npm ERR! Actual: {"npm":"1.0.106","node":"0.6.5"}
npm ERR!
npm ERR! System Darwin 11.2.0
npm ERR! command "node" "/usr/local/bin/npm" "install"
npm ERR! cwd /iodocs
npm ERR! node -v v0.6.5
npm ERR! npm -v 1.0.106
npm ERR! code ENOTSUP
npm ERR!


Should I downgrade?

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.