32 lines
1.6 KiB
Markdown
32 lines
1.6 KiB
Markdown
# Waiter Floor Workflow API
|
|
|
|
## Purpose
|
|
|
|
This BFF exposes execution-facing waiter workflows over REST while delegating orchestration to `operations-service`.
|
|
|
|
## Endpoints
|
|
|
|
- `GET /api/waiter/floor/assignments?contextId=<value>`
|
|
- Returns assignment summary, location context, current assignments, and recent activity.
|
|
- `GET /api/waiter/floor/activity?contextId=<value>`
|
|
- Returns recent waiter activity projected from the same operations workflow snapshot.
|
|
- `POST /api/waiter/floor/orders`
|
|
- Submits a waiter order snapshot for processing.
|
|
- `PUT /api/waiter/floor/orders/{orderId}`
|
|
- Updates an existing waiter order snapshot using the same operations workflow contract.
|
|
|
|
## Upstream Dependency
|
|
|
|
- Base address configuration: `OperationsService:BaseAddress`
|
|
- Default runtime target: `http://operations-service:8080`
|
|
- Internal upstream routes:
|
|
- `GET /internal/operations/waiter/assignments`
|
|
- `POST /internal/operations/orders`
|
|
|
|
## Notes
|
|
|
|
- The update route currently reuses the operations order submission contract so waiter-floor can expose update semantics without introducing a new cross-repo dependency.
|
|
- Both order mutations project into the shared restaurant lifecycle owned by `operations-service`, which means kitchen and POS can observe the same order/check state through the same runtime path.
|
|
- Assignment and recent-activity reads are already lifecycle-backed through `operations-service`, so this BFF does not need a separate summary-projection fallback for the Stage 49 propagation wave.
|
|
- Correlation IDs are preserved through Thalos session checks and operations-service calls.
|