37 lines
1.8 KiB
Markdown
37 lines
1.8 KiB
Markdown
# Kitchen Ops Workflow API
|
|
|
|
## Purpose
|
|
|
|
This BFF exposes kitchen board, claim or release, transition, and priority workflows over REST while delegating orchestration to `kitchen-service`.
|
|
|
|
## Endpoints
|
|
|
|
- `GET /api/kitchen/ops/board?contextId=<value>`
|
|
- Returns board lanes and available stations.
|
|
- `POST /api/kitchen/ops/work-items/claim`
|
|
- Claims a kitchen work item.
|
|
- `POST /api/kitchen/ops/work-items/release`
|
|
- Releases a kitchen work item using the current claim workflow path.
|
|
- `POST /api/kitchen/ops/work-items/transition`
|
|
- Requests a kitchen work-item state transition.
|
|
- `POST /api/kitchen/ops/board/priority`
|
|
- Updates kitchen priority for a work item.
|
|
|
|
## Upstream Dependency
|
|
|
|
- Base address configuration: `KitchenService:BaseAddress`
|
|
- Default runtime target: `http://kitchen-service:8080`
|
|
- Internal upstream routes:
|
|
- `GET /internal/kitchen/board`
|
|
- `POST /internal/kitchen/work-items/claim`
|
|
- `POST /internal/kitchen/orders/transition`
|
|
- `POST /internal/kitchen/work-items/priority`
|
|
|
|
## Notes
|
|
|
|
- `kitchen-service` currently exposes claim but not a dedicated release contract, so the release route reuses the claim validation path and projects a release-oriented response for the BFF edge.
|
|
- Transition requests now forward `ContextId` to `kitchen-service` so kitchen actions land in the correct shared restaurant lifecycle context.
|
|
- Board reads now rely on the lifecycle-driven kitchen ticket materialization in `kitchen-service`, which means newly accepted restaurant orders can appear without a stack reset.
|
|
- The BFF keeps temporary edge-state compatibility for existing web clients by translating `Cooking|Ready|Served` to the canonical kitchen-service states `Preparing|ReadyForPickup|Delivered`.
|
|
- Correlation IDs are preserved through Thalos session checks and kitchen-service calls.
|