c/p bug, fix operationIds, move rst docs to md
This commit is contained in:
parent
3e4962f211
commit
53137a3c53
4 changed files with 15 additions and 16 deletions
|
@ -214,7 +214,7 @@ paths:
|
|||
This API is called by the homeserver when it wants to present clients
|
||||
with specific information about the various third party networks that
|
||||
an application service supports.
|
||||
operationId: queryMetadata
|
||||
operationId: getProtocolMetadata
|
||||
parameters:
|
||||
- in: path
|
||||
name: protocol
|
||||
|
|
|
@ -27,5 +27,5 @@ properties:
|
|||
type: object
|
||||
example:
|
||||
"user": "jim"
|
||||
title: Location
|
||||
title: User
|
||||
type: object
|
|
@ -34,7 +34,7 @@ paths:
|
|||
Fetches the overall metadata about protocols supported by the
|
||||
homeserver. Includes both the available protocols and all fields
|
||||
required for queries against each protocol.
|
||||
operationId: queryMetadata
|
||||
operationId: getProtocols
|
||||
responses:
|
||||
200:
|
||||
description: The protocols supported by the homeserver.
|
||||
|
@ -45,7 +45,7 @@ paths:
|
|||
summary: Retrieve metadata about a specific protocol that the homeserver supports.
|
||||
description: |-
|
||||
Fetches the metadata from the homeserver about a particular third party protocol.
|
||||
operationId: queryMetadata
|
||||
operationId: getProtocolMetadata
|
||||
parameters:
|
||||
- in: path
|
||||
name: protocol
|
||||
|
@ -122,8 +122,9 @@ paths:
|
|||
required: true
|
||||
x-example: irc
|
||||
- in: query
|
||||
name: fields...
|
||||
type: string
|
||||
name: fields
|
||||
explode: true
|
||||
type: object
|
||||
description: |-
|
||||
One or more custom fields that are passed to the AS to help identify the user.
|
||||
responses:
|
||||
|
|
|
@ -1,5 +1,4 @@
|
|||
OpenAPI Extensions
|
||||
==================
|
||||
# OpenAPI Extensions
|
||||
|
||||
For some functionality that is not directly provided by the OpenAPI v2
|
||||
specification, some extensions have been added that are to be consistent
|
||||
|
@ -7,17 +6,16 @@ across the specification. The defined extensions are listed below. Extensions
|
|||
should not break parsers, however if extra functionality is required, aware
|
||||
parsers should be able to take advantage of the added syntax.
|
||||
|
||||
Extensible Query Parameters
|
||||
---------------------------
|
||||
## Extensible Query Parameters
|
||||
|
||||
If a unknown amount of query parameters can be added to a request, the
|
||||
``name`` should be in form of ``something...``, with the trailing ellipses
|
||||
representing the possibility of more fields.
|
||||
If a unknown amount of query parameters can be added to a request, the `name`
|
||||
must be `fields...`, with the trailing ellipses representing the possibility
|
||||
of more fields.
|
||||
|
||||
Example:
|
||||
|
||||
.. code-block::
|
||||
|
||||
```
|
||||
- in: query
|
||||
name: fields...
|
||||
type: string
|
||||
type: string
|
||||
```
|
Loading…
Add table
Add a link
Reference in a new issue