(WIP)
Background
There is a need for an API that allows create / update of stop places in Tiamat. This should be separate from the existing GraphQL (reserved for Abzu only).
Considerations
- Extract validation currently handled through the GraphQL endpoint. New API should adhere to the same validation rules.
- Need to discuss batch updates!
Working theory
- Async API (creating job tasks for each write operation) and a write queue for handling subsequent calls.
- Methods: GET, POST, PATCH, DELETE
No DELETE: patch to make stop place expired
- Data format: Netex xml
<stopPlaces>
<StopPlace ... />
</stopPlaces>
Only supports one (1) single stop in the list in first api edition.
If multimodal support is added in the feature, we will allow all stops that composes the multimodal in the list.
Batch updates is not planned.
The entire stop place entity needs to be sent. Tiamat will need to find what has been changed/added/removed when the client does a PATCH request.
We ignore all datetimes and let Tiamat handle setting these.
GET /stop-places/<id>
=> Return stop place with id
Use the read API for this
POST /stop-places
=> Return 202 Accepted with jobId
{ "jobId": 123 }
PATCH /stop-places
=> Return 202 Accepted with jobId
Concurrent updates: Use version difference to only allow first initiator.
DELETE /stop-places/<id>
=> Return 202 Accepted with jobId
This deactivates the stop.
GET /job/<id>
=> Return status of job with id
Example of pending job:
{
"id": 123,
"status": ENUM? or status codes?
}Example of successful create:
{
"id": 123,
"status": ENUM? or status codes?
}Example of successful update:
{
"id": 123,
"status": ENUM? or status codes?
}Example of failed update:
{
"id": 123,
"status": ENUM? or status codes?,
"reason": "Concurrent update"
}
(WIP)
Background
There is a need for an API that allows create / update of stop places in Tiamat. This should be separate from the existing GraphQL (reserved for Abzu only).
Considerations
Working theory
No DELETE: patch to make stop place expiredOnly supports one (1) single stop in the list in first api edition.
If multimodal support is added in the feature, we will allow all stops that composes the multimodal in the list.
Batch updates is not planned.
The entire stop place entity needs to be sent. Tiamat will need to find what has been changed/added/removed when the client does a PATCH request.
We ignore all datetimes and let Tiamat handle setting these.
GET /stop-places/<id>=> Return stop place with idUse the read API for this
POST /stop-places
=> Return 202 Accepted with jobId
{ "jobId": 123 }
PATCH /stop-places
=> Return 202 Accepted with jobId
Concurrent updates: Use version difference to only allow first initiator.
DELETE /stop-places/<id>
=> Return 202 Accepted with jobId
This deactivates the stop.
GET /job/<id>
=> Return status of job with id
Example of pending job:
{ "id": 123, "status": ENUM? or status codes? }Example of successful create:
{ "id": 123, "status": ENUM? or status codes? }Example of successful update:
{ "id": 123, "status": ENUM? or status codes? }Example of failed update:
{ "id": 123, "status": ENUM? or status codes?, "reason": "Concurrent update" }