Vendor Management API
A backend service for the part of procurement nobody enjoys: knowing which suppliers actually deliver on time, and which ones only look like they do.
It models vendors and purchase orders as first-class resources, then derives performance from the order history rather than asking anyone to maintain a scorecard by hand.
The problem
Vendor performance usually lives in a spreadsheet that goes stale the moment someone forgets to update it. The data needed to answer “is this supplier reliable?” already exists inside the purchase orders — it is just never connected to anything.
Approach
Two core resources, both full REST collections: vendors and purchase orders, with the standard verbs on each, so the API is predictable before it tries to be clever.
Performance then hangs off the vendor as its own endpoint — GET /api/vendors/{id}/performance — instead of being denormalised into the vendor record. A metric computed on read cannot drift out of sync with the orders it came from.
Purchase orders carry an explicit acknowledgement endpoint rather than overloading a generic update, because acknowledgement is a real event in the vendor relationship and deserves to be visible as one.
What it taught me
- Derived data belongs behind an endpoint, not in a column somebody has to remember to refresh.
- State transitions that matter to the business deserve named endpoints, not a PATCH with a magic field.