You are here. See how this question connects to other ideas.
Select a node to open its page · Expand to read within the map
One question
Why do operation semantics matter?
Naming a resource is useful only when consumers can understand what operations on it mean.
Listing discovers children. Reading obtains content. Writing changes supported content. Executing invokes an action. These are distinct operations with distinct effects; a familiar path must not hide an unexpected change of meaning.
For example, an interface redesign should not silently turn a read into a mutation. Agents need to reason about effects just as human users do. Uniform operations provide a common starting point across resources.
They do not imply identical latency, atomicity or failure behavior across providers. Those properties belong in the relevant contract and must be tested.
One task, four different requests
These are teaching addresses, not runnable endpoints.
| Intent | Operation meaning | Expected effect |
|---|---|---|
| Find tasks | List /work/tasks | Discover available children |
| Read a title | Read /work/tasks/keynote/title | Obtain its current text |
| Edit the title | Write a new value to a writable title resource | Change that content |
| Submit for review | Execute the application’s submission action | Check its rules and perform its effects |
An explicit submission action preserves business meaning. It may validate required information or record a submission; a button label does not make it equivalent to an arbitrary field write. The button’s appearance may change while the operation keeps its agreed effect.
Check your understanding
Why is “submit for review” not necessarily an ordinary write?
It may validate information, record a submission or have other business effects. Use its explicit operation contract instead of guessing a field to change.
Continue along a learning path
- Start with AFSStep 4 of 5
- What should endure?Step 3 of 6