Action links for state transitions in Rest API - Step-by-Step Execution

Concept Flow - Action links for state transitions

Client requests resource

↓

Server sends resource with state and action links

↓

Client reads current state

↓

Client chooses an action link

↓

Client sends request to action link

↓

Server processes action and updates state

↓

Server responds with new state and updated action links

↓

Repeat or End

The client gets a resource with links to possible actions. It picks a link to change state. The server updates and sends back new state and links.

Execution Sample

Rest API

GET /order/123
Response:
{
  "state": "pending",
  "actions": {
    "pay": "/order/123/pay",
    "cancel": "/order/123/cancel"
  }
}

Client requests an order resource and receives its current state and links to possible actions.

Execution Table

Step	Client Action	Request Sent	Server Response	State After	Available Action Links
1	Request order resource	GET /order/123	{"state":"pending","actions":{"pay":"/order/123/pay","cancel":"/order/123/cancel"}}	pending	pay, cancel
2	Choose to pay	POST /order/123/pay	{"state":"paid","actions":{"ship":"/order/123/ship"}}	paid	ship
3	Choose to ship	POST /order/123/ship	{"state":"shipped","actions":{}}	shipped	none
4	Try to cancel after shipped	POST /order/123/cancel	{"error":"Action not allowed in current state"}	shipped	none

💡 No more valid actions after shipped state; cancel action rejected.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
state	none	pending	paid	shipped	shipped
available_actions	none	pay, cancel	ship	none	none

Key Moments - 3 Insights

Why can't the client cancel the order after it is shipped?

Because after step 3, the server response shows no 'cancel' action link available (see execution_table row 3). The client must follow only the provided action links.

How does the client know what actions are allowed next?

The server includes 'actions' links in each response (see execution_table rows 1-3). The client reads these links to decide the next valid action.

What happens if the client tries an action not in the links?

The server responds with an error message and does not change the state (see execution_table row 4). The client must only use provided action links.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state after the client chooses to pay (step 2)?

A pending

B shipped

C paid

D cancelled

💡 Hint

Check the 'State After' column in row 2 of the execution_table.

At which step does the server stop providing any action links?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look at the 'Available Action Links' column in the execution_table rows.

If the client tried to ship the order before paying, what would likely happen?

A Server accepts and changes state to shipped

B Server rejects because 'ship' link is not provided yet

C Server cancels the order

D Server ignores the request silently

💡 Hint

Refer to how the server only allows actions from provided links (see execution_table step 4).

Concept Snapshot

Action links in REST APIs guide clients on allowed state changes.
Server responses include current state and URLs for next actions.
Clients must follow these links to change state.
Trying actions not linked results in errors.
This keeps client and server in sync about valid transitions.

Full Transcript

In REST APIs, servers send resources with current state and action links. Clients read these links to know what they can do next. For example, an order in 'pending' state might have 'pay' and 'cancel' links. When the client chooses 'pay', it sends a request to that link. The server updates the order to 'paid' and sends back new links like 'ship'. If the client tries an action not linked, the server rejects it. This way, the client always knows valid next steps and the server controls state changes safely.