Responses schema fixes (#3650)

Fixes #2237.

Corrects the response schemas for:

```
PUT /user/{user_id}/account_data/{account_dataType}
PUT /user/{user_id}/rooms/{roomId}/account_data/{type}
PUT /directory/list/room/{roomId}
PUT /sendToDevice/{eventType}/{txnId}
POST /account/3pid
POST /account/3pid/add
POST /account/3pid/bind
```
pull/3684/head
Alexandre Franke 2 years ago committed by GitHub
parent 2e5cc42666
commit d3e39567f4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -0,0 +1 @@
Correct the schema for the responses for various API endpoints.

@ -67,6 +67,10 @@ paths:
200:
description:
The account_data was successfully added.
examples:
application/json: {}
schema:
type: object
tags:
- User data
get:
@ -151,6 +155,10 @@ paths:
200:
description:
The account_data was successfully added.
examples:
application/json: {}
schema:
type: object
tags:
- User data
get:

@ -149,26 +149,26 @@ paths:
application/json: {
"submit_url": "https://example.org/path/to/submitToken"
}
schema:
type: object
properties:
submit_url:
type: string
format: uri
description: |-
An optional field containing a URL where the client must
submit the validation token to, with identical parameters
to the Identity Service API's `POST
/validate/email/submitToken` endpoint (without the requirement
for an access token). The homeserver must send this token to the
user (if applicable), who should then be prompted to provide it
to the client.
schema:
type: object
properties:
submit_url:
type: string
format: uri
description: |-
An optional field containing a URL where the client must
submit the validation token to, with identical parameters
to the Identity Service API's `POST
/validate/email/submitToken` endpoint (without the requirement
for an access token). The homeserver must send this token to the
user (if applicable), who should then be prompted to provide it
to the client.
If this field is not present, the client can assume that
verification will happen without the client's involvement
provided the homeserver advertises this specification version
in the `/versions` response (ie: r0.5.0).
example: "https://example.org/path/to/submitToken"
If this field is not present, the client can assume that
verification will happen without the client's involvement
provided the homeserver advertises this specification version
in the `/versions` response (ie: r0.5.0).
example: "https://example.org/path/to/submitToken"
403:
description: The credentials could not be verified with the identity server.
examples:
@ -223,8 +223,8 @@ paths:
description: The addition was successful.
examples:
application/json: {}
schema:
type: object
schema:
type: object
401:
description: |-
The homeserver requires additional authentication information.
@ -282,8 +282,8 @@ paths:
description: The addition was successful.
examples:
application/json: {}
schema:
type: object
schema:
type: object
429:
description: This request was rate-limited.
schema:

@ -298,9 +298,10 @@ paths:
responses:
200:
description: The update succeeded.
examples:
application/json: {}
schema:
type: object
properties: {}
400:
description: |-
A parameter was incorrect. For example, the `algorithm` does not

@ -104,6 +104,8 @@ paths:
description: The visibility was updated, or no change was needed.
examples:
application/json: {}
schema:
type: object
404:
description: The room is not known to the server
examples:

@ -85,7 +85,8 @@ paths:
description:
The message was successfully sent.
examples:
application/json: {
}
application/json: {}
schema:
type: object
tags:
- Send-to-Device messaging

Loading…
Cancel
Save