-
Notifications
You must be signed in to change notification settings - Fork 5
Home
=======================
This function was developed with the assumption that the starting input would be the main api file, which would look like the following:
{ "endpoints":
[...]
}The include statement syntax looks like this:
{
"external":
{
"href": "./public/data/desired/data.json",
"type": "list"
}
}"type": "list" is used only when the contents of the file to be included is a list object that will be merged into an existing list. An example would be storing all the get methods for an endpoint as a list of objects in an external file.
Imports must be referenced relative to the installation directory.
Given a URI, this functionality should process the URI, then obtain and process the contents of the URI. Ex. - If we have the following:
{ "href": "file:///user/home/data.json" }The function would return the parsed JSON data from the data.json file.
Ex. - Given:
{ "href": "http://www.example.com/foo.json" }The function would return the parsed JSON data from foo.json, dealing with file/content retrieval from the web by parsing the URI.
Whatever term is typed into the search box, that term will be searched for in the json configuration file; API names (endpoint names) are not included in the search [probably something that should be changed].
Content parameters show what can be entered for POST and PUT methods. When a method's parameters are filled out, the method's corresponding text area will show what the JSON form would look like.
Note: Perhaps there's a better term than 'content parameters', but I do not know it. I call them such as they appear under the word 'Content' in the display, and in the 'content' block in the api description file.
Note 2: 'content' and 'contentType' are two variables introduced in this fork by @dgc-wh to be able to send the content body as part of PUT and POST requests. 'content' replaces the 'requestBody' variable.
A few new types are introduced specifically for content parameters.
- collection - a list of objects belonging to a property. eg - "collection" : [{ "prop": "val", "prop2": "val2" }, { "prop3": "val3", "prop4": "val4" }]
- object - a set of properties and values belonging to a single property. eg. - "obj" : { "prop": "val", "prop2": "val2" }
- list - a list of values belonging to a property. eg. - "list" : [ "val", "val2", "val3" ]
Here is an example api that shows usage of all of these new types.
{
"endpoints": [
{
"name": "Testing API",
"methods": [
{
"MethodName": "Modify an application",
"Synopsis": "Modify a single application | stub",
"HTTPMethod": "PUT",
"URI": "/application/:app_id",
"RequiresOAuth": "N",
"content": {
"schema":{"type":"string"},
"contentType":["application/json","application/xml"],
"parameters": [
{
"Name": "scan_schedule",
"Required": "N",
"Type": "object",
"Description": "| stub",
"parameters": [
{
"Name": "specs",
"Required": "N",
"Default": "",
"Type": "collection",
"Description": "",
"parameters": [
{
"Name": "type",
"Required": "N",
"Default": "",
"Type": "string",
"Description": ""
},
{
"Name": "cron_spec",
"Required": "N",
"Default": "",
"Type": "string",
"Description": ""
},
{
"Name": "duration",
"Required": "N",
"Default": "",
"Type": "integer",
"Description": "The unit of measure is 'seconds'."
}
]
},
{
"Name": "exclude_dirs",
"Required": "N",
"Type": "list",
"Description": "List of directories to be excluded. | stub",
"parameters": [
{
"Required": "N",
"Type": "string"
}
]
}
]
}
]
},
"parameters": [
{
"Name": "app_id",
"Required": "Y",
"Type": "integer",
"Description": "Application id of application to be modified. | stub"
}
]
}
]
}
]
}
Endpoints and methods are now links. When the url entered is a linked item, that item will be expanded upon page load.
Link to Bugs.