From 53f55e1fbd3eb7092a55873278b1d5f7c32be306 Mon Sep 17 00:00:00 2001 From: John Gatward Date: Wed, 4 Mar 2026 12:10:00 +0000 Subject: [PATCH] fix numbered points --- docs/books/api_design_patterns/part1/chapter1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/books/api_design_patterns/part1/chapter1.md b/docs/books/api_design_patterns/part1/chapter1.md index 11a0afe..f6c68d9 100644 --- a/docs/books/api_design_patterns/part1/chapter1.md +++ b/docs/books/api_design_patterns/part1/chapter1.md @@ -33,7 +33,7 @@ Consider the following API method names: 4. `CancelReservation()` 5. `RescheduleFlight()` 6. `UpgradeTrip()` - +
- Each one of these RPCs is pretty descriptive, but we have to memorize these methods, each of which is subtly different. - e.g. sometimes we talk about flight, other times we talk about a trip or a reservation. - We also need to memorise which action is used in the method. @@ -46,7 +46,7 @@ We need to standardise, by providing a standard set of building blocks - method- 3. `ListFlightReservation()` 4. `DeleteFlightReservation()` 5. `UpdateFlightReservation()` - +
- Resource-oriented APIs will be much easier for users to learn, understand and remember. - Standardisation makes it easy to combine what you already know (set of standard actions) which the resource which is easy to learn.