Card 10/ 11
Practice: The Resources of a Ride-Sharing App
Riders, drivers, trips and ratings; name the resources, the paths, a cancellation and a search for nearby drivers.
Designing paths for a domain that looks nothing like a catalogue tests whether the method travels. A ride-sharing app has riders and drivers. A rider requests a trip, a driver accepts it, and after the trip each side may rate the other. Either may cancel a trip before it starts, and the rider's app shows available drivers within two kilometres.
Design the API's paths and methods for these operations:
- A rider requests a trip.
- Read one trip.
- A driver accepts a trip.
- A rider cancels a trip, giving a reason.
- A rider rates a trip.
- List a rider's past trips, newest first.
- Find available drivers near a location.
Show one good design
| Operation | Method and path | Why |
|---|---|---|
| Request a trip | POST /trips | Creates a trip; the server assigns its id |
| Read a trip | GET /trips/{id} | One canonical path per trip |
| Driver accepts | POST /trips/{id}/acceptance | Records who accepted and when |
| Rider cancels | POST /trips/{id}/cancellation | Keeps the trip, and stores the reason |
| Rate a trip | POST /trips/{id}/ratings | A rating belongs to one trip |
| A rider's past trips | GET /trips?riderId=31&status=completed&sort=-endedAt | A filtered view of trips, not a second collection |
| Nearby drivers | GET /drivers?status=available&near=40.41,-3.70&radiusKm=2 | Location and radius are filters on drivers |
PATCH /trips/{id} with a new status is a fair alternative for acceptance if no details are kept. GET /riders/31/trips is a fair alternative for past trips, as a read-only view.
← → move through sections and cards