36b02edfc2
Fixes #3305 Fixes #3380 The idea here is to better distinguish between a 'raw' event (as we send over the wire), and the 'serialised' format, as sent in responses to the C-S api and in `PUT /_matrix/app/v1/transactions/{txnId}`. It's made more complicated by the fact that there are _two_ serialisation formats, one used by `/sync` and `/notifications`, and one by everything else (the difference being whether `room_id` is included). In an ideal world, we wouldn't repeat `SerialisedEvent` every time it's used, and instead just link to the first reference, but that's a job for another day. Another job for another day is to get rid of things like `sync_state_event.yaml` (which is now used only in one place, so should be inlined.)
76 lines
2.5 KiB
YAML
76 lines
2.5 KiB
YAML
# Copyright 2016 OpenMarket Ltd
|
|
# Copyright 2018 New Vector Ltd
|
|
#
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
# you may not use this file except in compliance with the License.
|
|
# You may obtain a copy of the License at
|
|
#
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
#
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
# See the License for the specific language governing permissions and
|
|
# limitations under the License.
|
|
swagger: '2.0'
|
|
info:
|
|
title: "Matrix Application Service API"
|
|
version: "1.0.0"
|
|
host: localhost:8008
|
|
schemes:
|
|
- https
|
|
- http
|
|
basePath: /_matrix/app/v1
|
|
produces:
|
|
- application/json
|
|
securityDefinitions:
|
|
$ref: definitions/security.yaml
|
|
paths:
|
|
"/transactions/{txnId}":
|
|
put:
|
|
summary: Send some events to the application service.
|
|
description: |-
|
|
This API is called by the homeserver when it wants to push an event
|
|
(or batch of events) to the application service.
|
|
|
|
Note that the application service should distinguish state events
|
|
from message events via the presence of a `state_key`, rather than
|
|
via the event type.
|
|
operationId: sendTransaction
|
|
security:
|
|
- homeserverAccessToken: []
|
|
parameters:
|
|
- in: path
|
|
name: txnId
|
|
type: string
|
|
description: |-
|
|
The transaction ID for this set of events. Homeservers generate
|
|
these IDs and they are used to ensure idempotency of requests.
|
|
required: true
|
|
x-example: "35"
|
|
- in: body
|
|
name: body
|
|
description: Transaction information
|
|
schema:
|
|
type: object
|
|
example: {
|
|
"events": [
|
|
{"$ref": "../../event-schemas/examples/m.room.member.yaml"},
|
|
{"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"}
|
|
]
|
|
}
|
|
properties:
|
|
events:
|
|
type: array
|
|
description: |-
|
|
A list of events, formatted as per the Client-Server API.
|
|
items:
|
|
$ref: "../client-server/definitions/client_event.yaml"
|
|
required: ["events"]
|
|
responses:
|
|
200:
|
|
description: The transaction was processed successfully.
|
|
examples:
|
|
application/json: {}
|
|
schema:
|
|
type: object
|