A short piece of fiction, written by API Evangelist. The reader is imagined; the post, and every number and quotation from it, is real: "I Do Wake Up Wanting To Update A Resource," Kin Lane, November 13, 2026, https://apievangelist.com/2026/11/13/i-do-wake-up-wanting-to-update-a-resource/
Priya read the post on her phone, standing in the kitchen while the kettle ticked. She builds backend services for a small company that makes scheduling software, and the first quoted line made her bristle a little, because it felt aimed at her. The post said "nobody wakes up wanting to update a resource". Her whole API was resources. She had been proud of how clean it was.
Then she kept reading and found the author pushing back on that same line. He had updated a transcript that morning, and a guest's details. Those were resources, and he wanted plain calls to change them. Priya relaxed, and then felt the second, less comfortable thing. He also described a task he didn't want to assemble from twelve calls, "Publish this conversation everywhere it goes", and she knew exactly which of her customers' jobs looked like that. Booking a recurring meeting for a team across three calendars took nine requests, in an order she had only ever documented in a support reply.
She put the phone down and picked it up again. Part of her wanted to argue. Layers sounded tidy, but someone still had to build and maintain the experience layer, and her team had four people. Adding a second API shape to a product that already had gaps felt like volunteering for more work. She noticed she was annoyed at the post for being right about the cost, not about the idea.
The section on events stung in a quieter way. She had no webhooks. Customers polled. She had seen their request logs and told herself it was fine.
What stayed with her was the last part, which she reread twice. Nobody should be handed everything. The author's answer was to define personas and use cases first, then tag the operations by who they serve. He called himself the uber persona who wants everything, and said most consumers are not. Then he said this was "a discovery and onboarding argument" more than a design one.
That, she thought, she could actually do. She could not build an experience layer this quarter or a webhook system this year, but she could find out which of her operations the person scheduling a team meeting needs, and which they will never touch.
The kettle had gone cold. She made tea anyway, sat down at her laptop, and opened the OpenAPI file for the scheduling service. She did not open a ticket or draft a proposal. She picked one persona, the office coordinator who books for other people, and added a tag to the six operations that person uses, leaving the other forty untouched. It took twenty minutes and a few arguments with herself about whether one endpoint belonged.
She left the nine-request booking sequence as it was, and she did not pretend that tagging fixed it. But she wrote one line in the pull request description saying this was the sequence worth turning into a single call, and she asked the coordinator's account owner on Monday whether anyone had ever tried to find those six operations without help.