Closed petrdvorak closed 3 years ago
Let's use a slightly more complex definition of endpoint:
<!-- begin API-PATH POST /some/path "Some path" -->
Such as:
<!-- begin API-PATH PUT /article "Edit article" -->
In other words, we should also define the "name" of the endpoint to be included in the menu...
So... one more improvement - I promise it is the last one. :) I introduced a new {% apidescription %}
tag for an API description. Here is the example of an expected markup:
<!-- begin API -->
<!-- begin API-PATH POST /note/edit "Edit Note" -->
### POST /note/edit
<!-- end API-PATH POST -->
<!-- begin API-DESCRIPTION -->
Edit an exisiting note.
<!-- end API-DESCRIPTION -->
<!-- begin API-REQUEST -->
{ "id": "12", "text": "Updated text" }
<!-- end API-REQUEST -->
<!-- begin API-RESPONSE -->
<!-- begin API-RESPONSE-TAB 200 -->
{ "status": "OK" }
<!-- end API-RESPONSE-TAB -->
<!-- begin API-RESPONSE-TAB 401 -->
{ "status": "ERROR", "message": "401 Unauthorized" }
<!-- end API-RESPONSE-TAB -->
<!-- end API-RESPONSE -->
<!-- end API -->
Depends on #48
OK, hope this is the final format:
<!-- begin API POST /note/edit -->
### Edit note
Edit an exisiting note.
#### Request
```
{
"id": "12",
"text": "Updated text"
}
```
#### Response 200
```
{
"status": "OK"
}
```
#### Response 400
```
{
"status": "ERROR",
"message": "401 Unauthorized"
}
```
<!-- end -->
Where
"Request"
title, defines request section"Response XXX"
title, defines response & response tab section@hvge It looks good in general but does not handle situations where no request description is present. Sometimes, the request is fully defined by the API definition (method + URI). This markup does not render correctly:
<!-- begin api GET /push/service/status -->
### Service Status
Send a system status response, with basic information about the running application.
<!-- begin remove -->
<table>
<tr>
<td>Method</td>
<td><code>GET</code></td>
</tr>
<tr>
<td>Resource URI</td>
<td>/push/service/status</td>
</tr>
</table>
<!-- end -->
#### Response 200
```json
{
"status": "OK",
"responseObject": {
"applicationName": "powerauth-push",
"applicationDisplayName": "PowerAuth Push Server",
"applicationEnvironment": "",
"version": "0.21.0",
"buildTime": "2019-01-22T14:59:14.954+0000",
"timestamp": "2019-01-22T15:00:28.399+0000"
}
}
applicationName
- Application name.applicationDisplayName
- Application display name.applicationEnvironment
- Application environment.version
- Version of Push server.buildTime
- Timestamp when the powerauth-push-server.war file was built.timestamp
- Current time on application.
Also, documentation with nested headers does not seem to work well:
<!-- begin api PUT /push/campaign/${id}/user/add -->
### Add Users To Campaign
Associate users to a specific campaign. Users are identified in request body as an array of strings.
#### Request
<!-- begin remove -->
<table>
<tr>
<td>Method</td>
<td><code>POST / PUT</code></td>
</tr>
<tr>
<td>Resource URI</td>
<td>/push/campaign/${ID}/user/add</td>
</tr>
</table>
<!-- end -->
##### Query Parameters
<table>
<tr>
<td>id</td>
<td>Campaign identifier</td>
</tr>
</table>
##### Request Body
```json
{
"requestObject": [
"1234567890",
"1234567891",
"1234567893"
]
}
{
"status": "OK"
}
In case we render data in API template, we should be able to interpret the follwing macros...
API root
... translate to: