Update content to call the new template for HTTP APIs
This commit is contained in:
parent
1d629bae40
commit
52f5e73a39
27 changed files with 98 additions and 98 deletions
|
@ -204,7 +204,7 @@ NOT alter (e.g. add more) events they were going to send within that
|
||||||
transaction ID on retries, as the application service may have already
|
transaction ID on retries, as the application service may have already
|
||||||
processed the events.
|
processed the events.
|
||||||
|
|
||||||
{{transactions\_as\_http\_api}}
|
{{% http-api spec="application-service" api="transactions" %}}
|
||||||
|
|
||||||
#### Querying
|
#### Querying
|
||||||
|
|
||||||
|
@ -227,9 +227,9 @@ about information about the entity such as room ID to room alias
|
||||||
mappings.
|
mappings.
|
||||||
{{% /boxes/rationale %}}
|
{{% /boxes/rationale %}}
|
||||||
|
|
||||||
{{query\_user\_as\_http\_api}}
|
{{% http-api spec="application-service" api="query_user" %}}
|
||||||
|
|
||||||
{{query\_room\_as\_http\_api}}
|
{{% http-api spec="application-service" api="query_room" %}}
|
||||||
|
|
||||||
#### Third party networks
|
#### Third party networks
|
||||||
|
|
||||||
|
@ -251,7 +251,7 @@ request the homeserver to search in a particular "network" (protocol),
|
||||||
the search fields will be passed along to the application service for
|
the search fields will be passed along to the application service for
|
||||||
filtering.
|
filtering.
|
||||||
|
|
||||||
{{protocols\_as\_http\_api}}
|
{{% http-api spec="application-service" api="protocols" %}}
|
||||||
|
|
||||||
### Client-Server API Extensions
|
### Client-Server API Extensions
|
||||||
|
|
||||||
|
@ -356,7 +356,7 @@ defined third party protocols. These room directories may be accessed by
|
||||||
clients through additional parameters on the `/publicRooms`
|
clients through additional parameters on the `/publicRooms`
|
||||||
client-server endpoint.
|
client-server endpoint.
|
||||||
|
|
||||||
{{appservice\_room\_directory\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="appservice_room_directory" %}}
|
||||||
|
|
||||||
### Referencing messages from a third party network
|
### Referencing messages from a third party network
|
||||||
|
|
||||||
|
|
|
@ -205,7 +205,7 @@ Some API endpoints may allow or require the use of `POST` requests
|
||||||
without a transaction ID. Where this is optional, the use of a `PUT`
|
without a transaction ID. Where this is optional, the use of a `PUT`
|
||||||
request is strongly recommended.
|
request is strongly recommended.
|
||||||
|
|
||||||
{{versions\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="versions" %}}
|
||||||
|
|
||||||
## Web Browser Clients
|
## Web Browser Clients
|
||||||
|
|
||||||
|
@ -301,7 +301,7 @@ specify parameter values. The flow for this method is as follows:
|
||||||
`m.identity_server` property is present, but does not have a
|
`m.identity_server` property is present, but does not have a
|
||||||
`base_url` value, then `FAIL_ERROR`.
|
`base_url` value, then `FAIL_ERROR`.
|
||||||
|
|
||||||
{{wellknown\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="wellknown" %}}
|
||||||
|
|
||||||
## Client Authentication
|
## Client Authentication
|
||||||
|
|
||||||
|
@ -1021,9 +1021,9 @@ client supports it, the client should redirect the user to the
|
||||||
is complete, the client will need to submit a `/login` request matching
|
is complete, the client will need to submit a `/login` request matching
|
||||||
`m.login.token`.
|
`m.login.token`.
|
||||||
|
|
||||||
{{login\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="login" %}}
|
||||||
|
|
||||||
{{logout\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="logout" %}}
|
||||||
|
|
||||||
#### Login Fallback
|
#### Login Fallback
|
||||||
|
|
||||||
|
@ -1044,7 +1044,7 @@ the login endpoint during the login process. For example:
|
||||||
|
|
||||||
### Account registration and management
|
### Account registration and management
|
||||||
|
|
||||||
{{registration\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="registration" %}}
|
||||||
|
|
||||||
#### Notes on password management
|
#### Notes on password management
|
||||||
|
|
||||||
|
@ -1069,11 +1069,11 @@ identifier that is found in an identity server. Note that an identifier
|
||||||
can be added and bound at the same time, depending on context.
|
can be added and bound at the same time, depending on context.
|
||||||
{{% /boxes/note %}}
|
{{% /boxes/note %}}
|
||||||
|
|
||||||
{{administrative\_contact\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="administrative_contact" %}}
|
||||||
|
|
||||||
### Current account information
|
### Current account information
|
||||||
|
|
||||||
{{whoami\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="whoami" %}}
|
||||||
|
|
||||||
#### Notes on identity servers
|
#### Notes on identity servers
|
||||||
|
|
||||||
|
@ -1148,7 +1148,7 @@ Matrix specification while other values may be used by servers using the
|
||||||
Java package naming convention. The capabilities supported by the Matrix
|
Java package naming convention. The capabilities supported by the Matrix
|
||||||
specification are defined later in this section.
|
specification are defined later in this section.
|
||||||
|
|
||||||
{{capabilities\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="capabilities" %}}
|
||||||
|
|
||||||
### `m.change_password` capability
|
### `m.change_password` capability
|
||||||
|
|
||||||
|
@ -1356,7 +1356,7 @@ The current endpoints which support lazy-loading room members are:
|
||||||
|
|
||||||
### API endpoints
|
### API endpoints
|
||||||
|
|
||||||
{{filter\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="filter" %}}
|
||||||
|
|
||||||
## Events
|
## Events
|
||||||
|
|
||||||
|
@ -1582,23 +1582,23 @@ take a copy of the state dictionary, and *rewind* S1, in order to
|
||||||
correctly calculate the display name for M0.
|
correctly calculate the display name for M0.
|
||||||
{{% /boxes/rationale %}}
|
{{% /boxes/rationale %}}
|
||||||
|
|
||||||
{{sync\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="sync" %}}
|
||||||
|
|
||||||
{{old\_sync\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="old_sync" %}}
|
||||||
|
|
||||||
### Getting events for a room
|
### Getting events for a room
|
||||||
|
|
||||||
There are several APIs provided to `GET` events for a room:
|
There are several APIs provided to `GET` events for a room:
|
||||||
|
|
||||||
{{rooms\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="rooms" %}}
|
||||||
|
|
||||||
{{message\_pagination\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="message_pagination" %}}
|
||||||
|
|
||||||
{{room\_initial\_sync\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="room_initial_sync" %}}
|
||||||
|
|
||||||
### Sending events to a room
|
### Sending events to a room
|
||||||
|
|
||||||
{{room\_state\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="room_state" %}}
|
||||||
|
|
||||||
**Examples**
|
**Examples**
|
||||||
|
|
||||||
|
@ -1647,7 +1647,7 @@ PUT /rooms/!roomid:domain/state/m.room.bgd.color
|
||||||
{ "color": "red", "hex": "#ff0000" }
|
{ "color": "red", "hex": "#ff0000" }
|
||||||
```
|
```
|
||||||
|
|
||||||
{{room\_send\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="room_send" %}}
|
||||||
|
|
||||||
### Redactions
|
### Redactions
|
||||||
|
|
||||||
|
@ -1686,7 +1686,7 @@ the topic to be removed from the room.
|
||||||
|
|
||||||
#### Client behaviour
|
#### Client behaviour
|
||||||
|
|
||||||
{{redaction\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="redaction" %}}
|
||||||
|
|
||||||
## Rooms
|
## Rooms
|
||||||
|
|
||||||
|
@ -1706,7 +1706,7 @@ permissions in this room. This includes:
|
||||||
See [Room Events](#room-events) for more information on these events. To
|
See [Room Events](#room-events) for more information on these events. To
|
||||||
create a room, a client has to use the following API.
|
create a room, a client has to use the following API.
|
||||||
|
|
||||||
{{create\_room\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="create_room" %}}
|
||||||
|
|
||||||
### Room aliases
|
### Room aliases
|
||||||
|
|
||||||
|
@ -1731,7 +1731,7 @@ have a room alias of `#alias:example.com`, this SHOULD be checked to
|
||||||
make sure that the room's ID matches the `room_id` returned from the
|
make sure that the room's ID matches the `room_id` returned from the
|
||||||
request.
|
request.
|
||||||
|
|
||||||
{{directory\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="directory" %}}
|
||||||
|
|
||||||
### Permissions
|
### Permissions
|
||||||
|
|
||||||
|
@ -1816,13 +1816,13 @@ The allowable state transitions of membership are:
|
||||||
/ban
|
/ban
|
||||||
```
|
```
|
||||||
|
|
||||||
{{list\_joined\_rooms\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="list_joined_rooms" %}}
|
||||||
|
|
||||||
#### Joining rooms
|
#### Joining rooms
|
||||||
|
|
||||||
{{inviting\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="inviting" %}}
|
||||||
|
|
||||||
{{joining\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="joining" %}}
|
||||||
|
|
||||||
#### Leaving rooms
|
#### Leaving rooms
|
||||||
|
|
||||||
|
@ -1848,9 +1848,9 @@ behaviour is the same as if they had left of their own accord. In
|
||||||
particular, the user is free to re-join if the room is not
|
particular, the user is free to re-join if the room is not
|
||||||
"invite-only".
|
"invite-only".
|
||||||
|
|
||||||
{{leaving\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="leaving" %}}
|
||||||
|
|
||||||
{{kicking\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="kicking" %}}
|
||||||
|
|
||||||
##### Banning users in a room
|
##### Banning users in a room
|
||||||
|
|
||||||
|
@ -1884,21 +1884,21 @@ A user must be explicitly unbanned with a request to
|
||||||
`/rooms/<room_id>/unban`\_ before they can re-join the room or be
|
`/rooms/<room_id>/unban`\_ before they can re-join the room or be
|
||||||
re-invited.
|
re-invited.
|
||||||
|
|
||||||
{{banning\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="banning" %}}
|
||||||
|
|
||||||
### Listing rooms
|
### Listing rooms
|
||||||
|
|
||||||
{{list\_public\_rooms\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="list_public_rooms" %}}
|
||||||
|
|
||||||
## User Data
|
## User Data
|
||||||
|
|
||||||
### User Directory
|
### User Directory
|
||||||
|
|
||||||
{{users\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="users" %}}
|
||||||
|
|
||||||
### Profiles
|
### Profiles
|
||||||
|
|
||||||
{{profile\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="profile" %}}
|
||||||
|
|
||||||
#### Events on Change of Profile Information
|
#### Events on Change of Profile Information
|
||||||
|
|
||||||
|
|
|
@ -23,7 +23,7 @@ These events can also be received in a `/events` response or in the
|
||||||
|
|
||||||
#### Client Behaviour
|
#### Client Behaviour
|
||||||
|
|
||||||
{{account\_data\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="account-data" %}}
|
||||||
|
|
||||||
#### Server Behaviour
|
#### Server Behaviour
|
||||||
|
|
||||||
|
|
|
@ -10,4 +10,4 @@ server state and data.
|
||||||
|
|
||||||
#### Client Behaviour
|
#### Client Behaviour
|
||||||
|
|
||||||
{{admin\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="admin" %}}
|
||||||
|
|
|
@ -34,7 +34,7 @@ look like:
|
||||||
|
|
||||||
Clients can upload and download content using the following HTTP APIs.
|
Clients can upload and download content using the following HTTP APIs.
|
||||||
|
|
||||||
{{content\_repo\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="content-repo" %}}
|
||||||
|
|
||||||
##### Thumbnails
|
##### Thumbnails
|
||||||
|
|
||||||
|
|
|
@ -13,7 +13,7 @@ Clients that implement this module should offer the user a list of
|
||||||
registered devices, as well as the means to update their display names.
|
registered devices, as well as the means to update their display names.
|
||||||
Clients should also allow users to delete disused devices.
|
Clients should also allow users to delete disused devices.
|
||||||
|
|
||||||
{{device\_management\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="device_management" %}}
|
||||||
|
|
||||||
#### Security considerations
|
#### Security considerations
|
||||||
|
|
||||||
|
|
|
@ -905,7 +905,7 @@ To avoid leaking of social graphs, servers will only allow users to see:
|
||||||
Users will not be able to see signatures made by other users'
|
Users will not be able to see signatures made by other users'
|
||||||
user-signing keys.
|
user-signing keys.
|
||||||
|
|
||||||
{{cross\_signing\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="cross_signing" %}}
|
||||||
|
|
||||||
#### Sharing keys between devices
|
#### Sharing keys between devices
|
||||||
|
|
||||||
|
@ -1050,7 +1050,7 @@ The `session_data` field in the backups is constructed as follows:
|
||||||
the resulting MAC are base64-encoded, and become the `mac` property
|
the resulting MAC are base64-encoded, and become the `mac` property
|
||||||
of the `session_data`.
|
of the `session_data`.
|
||||||
|
|
||||||
{{key\_backup\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="key_backup" %}}
|
||||||
|
|
||||||
##### Key exports
|
##### Key exports
|
||||||
|
|
||||||
|
@ -1369,7 +1369,7 @@ messages.
|
||||||
|
|
||||||
##### Key management API
|
##### Key management API
|
||||||
|
|
||||||
{{keys\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="keys" %}}
|
||||||
|
|
||||||
##### Extensions to /sync
|
##### Extensions to /sync
|
||||||
|
|
||||||
|
|
|
@ -14,7 +14,7 @@ an event.
|
||||||
There is a single HTTP API for retrieving event context, documented
|
There is a single HTTP API for retrieving event context, documented
|
||||||
below.
|
below.
|
||||||
|
|
||||||
{{event\_context\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="event_context" %}}
|
||||||
|
|
||||||
#### Security considerations
|
#### Security considerations
|
||||||
|
|
||||||
|
|
|
@ -10,4 +10,4 @@ service. The third party service does need to be matrix-aware in that it
|
||||||
will need to know to resolve matrix homeservers to exchange the user's
|
will need to know to resolve matrix homeservers to exchange the user's
|
||||||
token for identity information.
|
token for identity information.
|
||||||
|
|
||||||
{{openid\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="openid" %}}
|
||||||
|
|
|
@ -37,7 +37,7 @@ enum of one of the following:
|
||||||
Clients can manually set/get their presence using the HTTP APIs listed
|
Clients can manually set/get their presence using the HTTP APIs listed
|
||||||
below.
|
below.
|
||||||
|
|
||||||
{{presence\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="presence" %}}
|
||||||
|
|
||||||
##### Last active ago
|
##### Last active ago
|
||||||
|
|
||||||
|
|
|
@ -90,7 +90,7 @@ Clients MUST configure a Pusher before they will receive push
|
||||||
notifications. There is a single API endpoint for this, as described
|
notifications. There is a single API endpoint for this, as described
|
||||||
below.
|
below.
|
||||||
|
|
||||||
{{pusher\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="pusher" %}}
|
||||||
|
|
||||||
##### Listing Notifications
|
##### Listing Notifications
|
||||||
|
|
||||||
|
@ -98,7 +98,7 @@ A client can retrieve a list of events that it has been notified about.
|
||||||
This may be useful so that users can see a summary of what important
|
This may be useful so that users can see a summary of what important
|
||||||
messages they have received.
|
messages they have received.
|
||||||
|
|
||||||
{{notifications\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="notifications" %}}
|
||||||
|
|
||||||
##### Receiving notifications
|
##### Receiving notifications
|
||||||
|
|
||||||
|
@ -658,7 +658,7 @@ Definition:
|
||||||
Clients can retrieve, add, modify and remove push rules globally or
|
Clients can retrieve, add, modify and remove push rules globally or
|
||||||
per-device using the APIs below.
|
per-device using the APIs below.
|
||||||
|
|
||||||
{{pushrules\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="pushrules" %}}
|
||||||
|
|
||||||
##### Push Rules: Events
|
##### Push Rules: Events
|
||||||
|
|
||||||
|
|
|
@ -39,7 +39,7 @@ commonly updated at the same time, and therefore the client might wish
|
||||||
to save an extra HTTP call. Providing an `m.read` location performs the
|
to save an extra HTTP call. Providing an `m.read` location performs the
|
||||||
same task as a request to `/receipt/m.read/$event:example.org`.
|
same task as a request to `/receipt/m.read/$event:example.org`.
|
||||||
|
|
||||||
{{read\_markers\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="read_markers" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -58,7 +58,7 @@ for events sent by their own user.
|
||||||
A client can update the markers for its user by interacting with the
|
A client can update the markers for its user by interacting with the
|
||||||
following HTTP APIs.
|
following HTTP APIs.
|
||||||
|
|
||||||
{{receipts\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="receipts" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -14,7 +14,7 @@ offensive" and 0 is "inoffensive".
|
||||||
|
|
||||||
#### Client behaviour
|
#### Client behaviour
|
||||||
|
|
||||||
{{report\_content\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="report_content" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -25,7 +25,7 @@ Clients can of course also call other endpoints such as [GET
|
||||||
and [GET /search](#post_matrixclientr0search) to
|
and [GET /search](#post_matrixclientr0search) to
|
||||||
access events outside the `/events` stream.
|
access events outside the `/events` stream.
|
||||||
|
|
||||||
{{peeking\_events\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="peeking_events" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -24,7 +24,7 @@ old room. Another approach may be to virtually merge the rooms such that
|
||||||
the old room's timeline seamlessly continues into the new timeline
|
the old room's timeline seamlessly continues into the new timeline
|
||||||
without the user having to jump between the rooms.
|
without the user having to jump between the rooms.
|
||||||
|
|
||||||
{{room\_upgrades\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="room_upgrades" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -15,7 +15,7 @@ it won't include events in rooms that happened after you left.
|
||||||
There is a single HTTP API for performing server-side search, documented
|
There is a single HTTP API for performing server-side search, documented
|
||||||
below.
|
below.
|
||||||
|
|
||||||
{{search\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="search" %}}
|
||||||
|
|
||||||
#### Search Categories
|
#### Search Categories
|
||||||
|
|
||||||
|
|
|
@ -52,7 +52,7 @@ should be sent on to the remote servers via
|
||||||
|
|
||||||
#### Protocol definitions
|
#### Protocol definitions
|
||||||
|
|
||||||
{{to\_device\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="to_device" %}}
|
||||||
|
|
||||||
##### Extensions to /sync
|
##### Extensions to /sync
|
||||||
|
|
||||||
|
|
|
@ -104,7 +104,7 @@ The client starts the process by instructing the browser to navigate to
|
||||||
authentication is successful, the browser will be redirected to that
|
authentication is successful, the browser will be redirected to that
|
||||||
`redirectUrl`.
|
`redirectUrl`.
|
||||||
|
|
||||||
{{sso\_login\_redirect\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="sso_login_redirect" %}}
|
||||||
|
|
||||||
###### Security considerations
|
###### Security considerations
|
||||||
|
|
||||||
|
|
|
@ -63,4 +63,4 @@ tags are defined in the `m.*` namespace:
|
||||||
|
|
||||||
#### Client Behaviour
|
#### Client Behaviour
|
||||||
|
|
||||||
{{tags\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="tags" %}}
|
||||||
|
|
|
@ -37,7 +37,7 @@ invitee does indeed own that third party identifier. See the
|
||||||
|
|
||||||
A client asks a server to invite a user by their third party identifier.
|
A client asks a server to invite a user by their third party identifier.
|
||||||
|
|
||||||
{{third\_party\_membership\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="third_party_membership" %}}
|
||||||
|
|
||||||
#### Server behaviour
|
#### Server behaviour
|
||||||
|
|
||||||
|
|
|
@ -19,4 +19,4 @@ A client may wish to provide a rich interface for joining third party
|
||||||
locations and connecting with third party users. Information necessary
|
locations and connecting with third party users. Information necessary
|
||||||
for such an interface is provided by third party lookups.
|
for such an interface is provided by third party lookups.
|
||||||
|
|
||||||
{{third\_party\_lookup\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="third_party_lookup" %}}
|
||||||
|
|
|
@ -33,7 +33,7 @@ recommended. When the user stops typing, the state change of the
|
||||||
`boolean` to `false` should trigger another HTTP request to inform the
|
`boolean` to `false` should trigger another HTTP request to inform the
|
||||||
server that the user has stopped typing.
|
server that the user has stopped typing.
|
||||||
|
|
||||||
{{typing\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="typing" %}}
|
||||||
|
|
||||||
#### Security considerations
|
#### Security considerations
|
||||||
|
|
||||||
|
|
|
@ -82,7 +82,7 @@ The homeserver MAY provide a TURN server which clients can use to
|
||||||
contact the remote party. The following HTTP API endpoints will be used
|
contact the remote party. The following HTTP API endpoints will be used
|
||||||
by clients in order to get information about the TURN server.
|
by clients in order to get information about the TURN server.
|
||||||
|
|
||||||
{{voip\_cs\_http\_api}}
|
{{% http-api spec="client-server" api="voip" %}}
|
||||||
|
|
||||||
#### Security considerations
|
#### Security considerations
|
||||||
|
|
||||||
|
|
|
@ -172,7 +172,7 @@ header is inaccessible for the client.
|
||||||
When credentials are required but missing or invalid, the HTTP call will
|
When credentials are required but missing or invalid, the HTTP call will
|
||||||
return with a status of 401 and the error code `M_UNAUTHORIZED`.
|
return with a status of 401 and the error code `M_UNAUTHORIZED`.
|
||||||
|
|
||||||
{{v2\_auth\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_auth" %}}
|
||||||
|
|
||||||
## Terms of service
|
## Terms of service
|
||||||
|
|
||||||
|
@ -198,13 +198,13 @@ has just accepted are appended to `m.accepted_terms`.
|
||||||
|
|
||||||
{{m\_accepted\_terms\_event}}
|
{{m\_accepted\_terms\_event}}
|
||||||
|
|
||||||
{{v2\_terms\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_terms" %}}
|
||||||
|
|
||||||
## Status check
|
## Status check
|
||||||
|
|
||||||
{{ping\_is\_http\_api}}
|
{{% http-api spec="identity" api="ping" %}}
|
||||||
|
|
||||||
{{v2\_ping\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_ping" %}}
|
||||||
|
|
||||||
## Key management
|
## Key management
|
||||||
|
|
||||||
|
@ -217,15 +217,15 @@ The identity server may also keep track of some short-term
|
||||||
public-private keypairs, which may have different usage and lifetime
|
public-private keypairs, which may have different usage and lifetime
|
||||||
characteristics than the service's long-term keys.
|
characteristics than the service's long-term keys.
|
||||||
|
|
||||||
{{pubkey\_is\_http\_api}}
|
{{% http-api spec="identity" api="pubkey" %}}
|
||||||
|
|
||||||
{{v2\_pubkey\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_pubkey" %}}
|
||||||
|
|
||||||
## Association lookup
|
## Association lookup
|
||||||
|
|
||||||
{{lookup\_is\_http\_api}}
|
{{% http-api spec="identity" api="lookup" %}}
|
||||||
|
|
||||||
{{v2\_lookup\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_lookup" %}}
|
||||||
|
|
||||||
### Client behaviour
|
### Client behaviour
|
||||||
|
|
||||||
|
@ -398,21 +398,21 @@ through without modification.
|
||||||
|
|
||||||
### Email associations
|
### Email associations
|
||||||
|
|
||||||
{{email\_associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="email_associations" %}}
|
||||||
|
|
||||||
{{v2\_email\_associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_email_associations" %}}
|
||||||
|
|
||||||
### Phone number associations
|
### Phone number associations
|
||||||
|
|
||||||
{{phone\_associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="phone_associations" %}}
|
||||||
|
|
||||||
{{v2\_phone\_associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_phone_associations" %}}
|
||||||
|
|
||||||
### General
|
### General
|
||||||
|
|
||||||
{{associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="associations" %}}
|
||||||
|
|
||||||
{{v2\_associations\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_associations" %}}
|
||||||
|
|
||||||
## Invitation storage
|
## Invitation storage
|
||||||
|
|
||||||
|
@ -427,9 +427,9 @@ the Matrix user's homeserver via the
|
||||||
endpoint. The request MUST be signed with a long-term private key for
|
endpoint. The request MUST be signed with a long-term private key for
|
||||||
the identity server.
|
the identity server.
|
||||||
|
|
||||||
{{store\_invite\_is\_http\_api}}
|
{{% http-api spec="identity" api="store_invite" %}}
|
||||||
|
|
||||||
{{v2\_store\_invite\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_store_invite" %}}
|
||||||
|
|
||||||
## Ephemeral invitation signing
|
## Ephemeral invitation signing
|
||||||
|
|
||||||
|
@ -438,6 +438,6 @@ identity server offers some crypto functionality to help in accepting
|
||||||
invitations. This is less secure than the client doing it itself, but
|
invitations. This is less secure than the client doing it itself, but
|
||||||
may be useful where this isn't possible.
|
may be useful where this isn't possible.
|
||||||
|
|
||||||
{{invitation\_signing\_is\_http\_api}}
|
{{% http-api spec="identity" api="invitation_signing" %}}
|
||||||
|
|
||||||
{{v2\_invitation\_signing\_is\_http\_api}}
|
{{% http-api spec="identity" api="v2_invitation_signing" %}}
|
||||||
|
|
|
@ -54,4 +54,4 @@ Note that most of the values and behaviour of this endpoint is described
|
||||||
by the Client-Server API's [Push
|
by the Client-Server API's [Push
|
||||||
Module](/client-server-api#push-notifications).
|
Module](/client-server-api#push-notifications).
|
||||||
|
|
||||||
{{push\_notifier\_push\_http\_api}}
|
{{% http-api spec="push-gateway" api="push_notifier" %}}
|
||||||
|
|
|
@ -150,11 +150,11 @@ SNI is not supported and should not be sent.
|
||||||
Servers are encouraged to make use of the [Certificate
|
Servers are encouraged to make use of the [Certificate
|
||||||
Transparency](https://www.certificate-transparency.org/) project.
|
Transparency](https://www.certificate-transparency.org/) project.
|
||||||
|
|
||||||
{{wellknown\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="wellknown" %}}
|
||||||
|
|
||||||
### Server implementation
|
### Server implementation
|
||||||
|
|
||||||
{{version\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="version" %}}
|
||||||
|
|
||||||
### Retrieving server keys
|
### Retrieving server keys
|
||||||
|
|
||||||
|
@ -190,7 +190,7 @@ Homeservers publish their signing keys in a JSON object at
|
||||||
homeserver and for signing events. It contains a list of
|
homeserver and for signing events. It contains a list of
|
||||||
`old_verify_keys` which are only valid for signing events.
|
`old_verify_keys` which are only valid for signing events.
|
||||||
|
|
||||||
{{keys\_server\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="keys_server" %}}
|
||||||
|
|
||||||
#### Querying Keys Through Another Server
|
#### Querying Keys Through Another Server
|
||||||
|
|
||||||
|
@ -205,7 +205,7 @@ Notary servers can return keys for servers that are offline or having
|
||||||
issues serving their own keys by using cached responses. Keys can be
|
issues serving their own keys by using cached responses. Keys can be
|
||||||
queried from multiple servers to mitigate against DNS spoofing.
|
queried from multiple servers to mitigate against DNS spoofing.
|
||||||
|
|
||||||
{{keys\_query\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="keys_query" %}}
|
||||||
|
|
||||||
## Authentication
|
## Authentication
|
||||||
|
|
||||||
|
@ -308,7 +308,7 @@ pair of homeservers that exchanged it; they are not globally-meaningful.
|
||||||
Transactions are limited in size; they can have at most 50 PDUs and 100
|
Transactions are limited in size; they can have at most 50 PDUs and 100
|
||||||
EDUs.
|
EDUs.
|
||||||
|
|
||||||
{{transactions\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="transactions" %}}
|
||||||
|
|
||||||
## PDUs
|
## PDUs
|
||||||
|
|
||||||
|
@ -559,7 +559,7 @@ to check with other servers to ensure it is receiving the correct auth
|
||||||
chain. These APIs give the homeserver an avenue for getting the
|
chain. These APIs give the homeserver an avenue for getting the
|
||||||
information it needs.
|
information it needs.
|
||||||
|
|
||||||
{{event\_auth\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="event_auth" %}}
|
||||||
|
|
||||||
## EDUs
|
## EDUs
|
||||||
|
|
||||||
|
@ -623,7 +623,7 @@ Similar to backfilling a room's history, a server may not have all the
|
||||||
events in the graph. That server may use the `/get_missing_events` API
|
events in the graph. That server may use the `/get_missing_events` API
|
||||||
to acquire the events it is missing.
|
to acquire the events it is missing.
|
||||||
|
|
||||||
{{backfill\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="backfill" %}}
|
||||||
|
|
||||||
## Retrieving events
|
## Retrieving events
|
||||||
|
|
||||||
|
@ -632,7 +632,7 @@ information about the room which cannot be easily determined from
|
||||||
backfilling. These APIs provide homeservers with the option of getting
|
backfilling. These APIs provide homeservers with the option of getting
|
||||||
events and the state of the room at a given point in the timeline.
|
events and the state of the room at a given point in the timeline.
|
||||||
|
|
||||||
{{events\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="events" %}}
|
||||||
|
|
||||||
## Joining Rooms
|
## Joining Rooms
|
||||||
|
|
||||||
|
@ -716,9 +716,9 @@ graph, and responds to the joining server with the full set of state for
|
||||||
the newly-joined room. The resident server must also send the event to
|
the newly-joined room. The resident server must also send the event to
|
||||||
other servers participating in the room.
|
other servers participating in the room.
|
||||||
|
|
||||||
{{joins\_v1\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="joins-v1" %}}
|
||||||
|
|
||||||
{{joins\_v2\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="joins-v2" %}}
|
||||||
|
|
||||||
## Inviting to a room
|
## Inviting to a room
|
||||||
|
|
||||||
|
@ -728,9 +728,9 @@ the process defined here. However, when a user invites another user on a
|
||||||
different homeserver, a request to that homeserver to have the event
|
different homeserver, a request to that homeserver to have the event
|
||||||
signed and verified must be made.
|
signed and verified must be made.
|
||||||
|
|
||||||
{{invites\_v1\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="invites-v1" %}}
|
||||||
|
|
||||||
{{invites\_v2\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="invites-v2" %}}
|
||||||
|
|
||||||
## Leaving Rooms (Rejecting Invites)
|
## Leaving Rooms (Rejecting Invites)
|
||||||
|
|
||||||
|
@ -751,9 +751,9 @@ and replaces the `event_id` with its own. This is then sent to the
|
||||||
resident server via `/send_leave`. The resident server will then send
|
resident server via `/send_leave`. The resident server will then send
|
||||||
the event to other servers in the room.
|
the event to other servers in the room.
|
||||||
|
|
||||||
{{leaving\_v1\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="leaving-v1" %}}
|
||||||
|
|
||||||
{{leaving\_v2\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="leaving-v2" %}}
|
||||||
|
|
||||||
## Third-party invites
|
## Third-party invites
|
||||||
|
|
||||||
|
@ -806,7 +806,7 @@ auth the event and send it.
|
||||||
However, if the invited homeserver isn't in the room the invite came
|
However, if the invited homeserver isn't in the room the invite came
|
||||||
from, it will need to request the room's homeserver to auth the event.
|
from, it will need to request the room's homeserver to auth the event.
|
||||||
|
|
||||||
{{third\_party\_invite\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="third_party_invite" %}}
|
||||||
|
|
||||||
#### Verifying the invite
|
#### Verifying the invite
|
||||||
|
|
||||||
|
@ -841,7 +841,7 @@ homeservers need a way to query the public rooms for another server.
|
||||||
This can be done by making a request to the `/publicRooms` endpoint for
|
This can be done by making a request to the `/publicRooms` endpoint for
|
||||||
the server the room directory should be retrieved for.
|
the server the room directory should be retrieved for.
|
||||||
|
|
||||||
{{public\_rooms\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="public_rooms" %}}
|
||||||
|
|
||||||
## Typing Notifications
|
## Typing Notifications
|
||||||
|
|
||||||
|
@ -885,7 +885,7 @@ There are several types of queries that can be made. The generic
|
||||||
endpoint to represent all queries is described first, followed by the
|
endpoint to represent all queries is described first, followed by the
|
||||||
more specific queries that can be made.
|
more specific queries that can be made.
|
||||||
|
|
||||||
{{query\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="query" %}}
|
||||||
|
|
||||||
## OpenID
|
## OpenID
|
||||||
|
|
||||||
|
@ -897,7 +897,7 @@ without granting full access to the user's account.
|
||||||
Access tokens generated by the OpenID API are only good for the OpenID
|
Access tokens generated by the OpenID API are only good for the OpenID
|
||||||
API and nothing else.
|
API and nothing else.
|
||||||
|
|
||||||
{{openid\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="openid" %}}
|
||||||
|
|
||||||
## Device Management
|
## Device Management
|
||||||
|
|
||||||
|
@ -943,7 +943,7 @@ recognise, it must resynchronise its list by calling the
|
||||||
`stream_id` which should be used to correlate with subsequent
|
`stream_id` which should be used to correlate with subsequent
|
||||||
`m.device_list_update` EDUs.
|
`m.device_list_update` EDUs.
|
||||||
|
|
||||||
{{user\_devices\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="user_devices" %}}
|
||||||
|
|
||||||
{{definition\_ss\_event\_schemas\_m\_device\_list\_update}}
|
{{definition\_ss\_event\_schemas\_m\_device\_list\_update}}
|
||||||
|
|
||||||
|
@ -958,7 +958,7 @@ The APIs defined here are designed to be able to proxy much of the
|
||||||
client's request through to federation, and have the response also be
|
client's request through to federation, and have the response also be
|
||||||
proxied through to the client.
|
proxied through to the client.
|
||||||
|
|
||||||
{{user\_keys\_ss\_http\_api}}
|
{{% http-api spec="server-server" api="user_keys" %}}
|
||||||
|
|
||||||
{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}
|
{{definition\_ss\_event\_schemas\_m\_signing\_key\_update}}
|
||||||
|
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue