-
Notifications
You must be signed in to change notification settings - Fork 128
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ANCHOR-339] Add the /event endpoint to Callback API.yml #184
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -466,3 +466,34 @@ paths: | |
application/json: | ||
schema: | ||
$ref: './schemas.yml#/components/schemas/Error' | ||
/event: | ||
post: | ||
tags: | ||
- Events | ||
- SEP-24 | ||
- SEP-31 | ||
summary: Receive a event from the anchor platform. | ||
operationId: postEvent | ||
description: | | ||
Receive a JSON object representing an event. | ||
requestBody: | ||
content: | ||
application/json: | ||
schema: | ||
type: object | ||
properties: | ||
timestamp: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is timestamp not a part of an event? |
||
type: string | ||
description: | | ||
`timestamp` the current Unix timestamp (number of seconds since epoch) at the time event is sent. | ||
payload: | ||
$ref: './schemas.yml#/components/schemas/Event' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is now a good time to revisit the schema?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also, do we need a timestamp on each event to ensure business can check if they've already processed an event after the one received? Is that possible? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The For And we should have a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we redesigning event schema in the separate PR this change LGTM |
||
responses: | ||
'200': | ||
description: The event is successfully processed and ready to receive next event. The response body is empty. | ||
'400': | ||
description: The event is invalid or rejected. The response body contains the error message. | ||
Comment on lines
+494
to
+495
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure we want to define any non-200 response code. All responses should have 200, and all other response codes will be interpreted as an error and retries will be made according to the AP's strategy. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The response code is limited The retries can be handled in the next fix version. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But 400 itself is not a valid status, so I don't think we should define it in the spec. |
||
|
||
|
||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[an event]