{ "Link Relations": { "type": "directory", "name": "Link Relations", "base_name": "Link Relations", "README.md": { "type": "file", "name": "README.md", "base_name": "README", "output_name": "README.html", "raw": "## Link Relations\n\nThis application supports the following\n[Link Relations](http://www.iana.org/assignments/link-relations/link-relations.xml),\nwhich are listed using\n[MultiMarkdown Table Syntax](http://fletcher.github.com/peg-multimarkdown/mmd-manual.pdf):\n\n| Link Relation | Interpretation |\n| ------------- | ------------- |\n| first | First entry in the set |\n| previous | Previous set of entries |\n| next | Next set of entries |\n| last | Last set of entries |\n", "parsed": "
This application supports the following\nLink Relations,\nwhich are listed using\nMultiMarkdown Table Syntax:
\n\nLink Relation | \nInterpretation | \n
---|---|
first | \nFirst entry in the set | \n
previous | \nPrevious set of entries | \n
next | \nNext set of entries | \n
last | \nLast set of entries | \n
A popular application type\nthat often needs application-specific information. Sometimes the\nbest you can do is provide an example\n(note the highlights.js styling)
\n\n{\n "glossary": {\n "title": "example glossary",\n "GlossDiv": {\n "title": "S",\n "GlossList": {\n "GlossEntry": {\n "ID": "SGML",\n "SortAs": "SGML",\n "GlossTerm": "Standard Generalized Markup Language",\n "Acronym": "SGML",\n "Abbrev": "ISO 8879:1986",\n "GlossDef": {\n "para": "A meta-markup language, used to create markup languages such as DocBook.",\n "GlossSeeAlso": ["GML", "XML"]\n },\n "GlossSee": "markup"\n }\n }\n }\n }\n}\n
\n"
}
},
"Resources": {
"type": "directory",
"name": "Resources",
"base_name": "Resources",
"items": {
"type": "directory",
"name": "items",
"base_name": "items",
"{item_id}": {
"type": "directory",
"name": "{item_id}",
"base_name": "{item_id}",
"DELETE.md": {
"type": "file",
"name": "DELETE.md",
"base_name": "DELETE",
"output_name": "DELETE.html",
"raw": "## DELETE /items/{item_id}\n\nDelete `item_id` resource",
"parsed": "Delete item_id
resource
GET item_id
representation
Update item_id
representation
Get the list of all items
\n" }, "index.md": { "type": "file", "name": "index.md", "base_name": "index", "output_name": "index.html", "raw": "### Items\n\nItems are the core of the API. They are so important it's impossible to adequately define them.", "parsed": "Items are the core of the API. They are so important it's impossible to adequately define them.
\n" }, "POST.md": { "type": "file", "name": "POST.md", "base_name": "POST", "output_name": "POST.html", "raw": "## POST /items\n\nPOST a new item to the collection", "parsed": "POST a new item to the collection
\n" } }, "README.md": { "type": "file", "name": "README.md", "base_name": "README", "output_name": "README.html", "raw": "## Resources\n\nIf [Level 3](http://martinfowler.com/articles/richardsonMaturityModel.html)\n[HATEOS](http://en.wikipedia.org/wiki/HATEOAS) is an aspirational goal\nfor your service, then resources are probably pretty important to you.\n\nNote that the the `/items/{item_id}` resource uses a\n[URL Template](http://www.mnot.net/javascript/url_template/) pattern\nto emphasize to your clients that they need to substitute a value.\n\nThis README is often a good place to put common service information such\nas:\n\n * ETags\n * Authentication\n * Rate Throttling\n * etc.", "parsed": "If Level 3\nHATEOS is an aspirational goal\nfor your service, then resources are probably pretty important to you.
\n\nNote that the the /items/{item_id}
resource uses a\nURL Template pattern\nto emphasize to your clients that they need to substitute a value.
This README is often a good place to put common service information such\nas:
\n\nNapiDocs is a set of Node.js command line scripts\nthat transform a directory of Markdown files and supporting resources\ninto a static HTML site pages documenting a REST-style service.
\n\nnode napidocs.js init -t ~/NapiDocs"
\n\n/_static
: Static resources (CSS, JS) that will be copied to the target output/build
: The built output that should be statically hosted./docs
: The tree of Markdown files that comprise your service's documentation./plugins
: Plugins used to transform the internal documentation tree to HTML output. Plugins are referenced in the /template/api.html
file./template
: Includes the api.html
file that is used to generate each documentation page.node napidocs.js preview -s ~/NapiDocs
\n\n-p/--port
command line argument/template/api.html
:\n\n/docs
child directories are transformed into Group headers in the sidebar. Delete any immediate directories that don't apply to your service.node napidocs.js build --source ~/NapiDocs
~/NapiDocs/build
) on a static server.\n\nIf you want to customize the output, you can write a custom plugin and reference it in /template/api.html
. For example:
<ul class="nav nav-list">\n <%= my_custom_plugin %>\n</ul>\n
\n\nwill instruct NapiDocs to look for ~/NapiDocs/plugins/my_custom_plugin.js
\nin the documentation directory.
Plugins must export a single function:
\n\n/**\n * Return HTML for the given asset object\n * @param {Object} asset_obj The current asset being rendered (Markdown or directory)\n * @param {Object} parent_obj The parent asset of asset_obj, may be null/empty\n * @param {Object} all_data The entire accumulated internal documentation representation\n * @return {String} HTML content\n */\nmodule.exports = function(asset_obj, parent_obj, all_data)\n{\n // Return HTML string\n}\n
\n\nThe internal documentation representation is visible by providing the -d/--dump
command line\noption to the node napidocs.js build
command.