Resource orientation designs an API around named resources and a small, standardized set of operations. Instead of inventing an action for every behavior, designers combine familiar methods with resources such as FlightReservation, making interfaces easier to learn, understand, and remember. section 1.3 section 1.5
Prefer resource orientation when consistency and discoverability matter, but compare it with RPC-style designs:
- Arbitrary RPC methods might use ScheduleFlight(), GetFlightDetails(), CancelReservation(), and RescheduleFlight(), forcing users to remember many names and resource distinctions. section 1.3
- A resource-oriented design standardizes Create, Get, List, Delete, and Update across resources, producing methods such as CreateFlightReservation() and ListFlightReservations(). section 1.3
- Do not treat resource orientation as universally superior: RPC-oriented APIs can fit some stateless scenarios, while standardized resources often improve usability elsewhere. section 1.3
Table 1.2 Summary of standard methods and their meanings (view table figure)
Use the standard-method table to map Create, Get, List, Delete, and Update to their intended operations. section 1.3
Flight reservations
Model FlightReservation as the resource, then expose CreateFlightReservation(), GetFlightReservation(), ListFlightReservations(), DeleteFlightReservation(), and UpdateFlightReservation(). This replaces a scattered collection of flight- and reservation-specific actions with a predictable method pattern. section 1.3
