Noun-based resource naming in Rest API - Step-by-Step Execution

Concept Flow - Noun-based resource naming

Client sends HTTP request

↓

Request targets resource URL

↓

Resource named as noun (e.g., /users)

↓

Server processes request on resource

↓

Server returns response with resource data

The client sends a request to a URL named as a noun representing the resource. The server processes this noun-based resource and returns the appropriate data.

Execution Sample

Rest API

GET /users HTTP/1.1
Host: example.com

Response: 200 OK
[
  {"id":1,"name":"Alice"},
  {"id":2,"name":"Bob"}
]

A client requests the 'users' resource using a noun-based URL and receives a list of users.

Execution Table

Step	HTTP Method	URL	Resource Name	Action	Response
1	GET	/users	users	Retrieve list of users	200 OK with user list
2	POST	/users	users	Create new user	201 Created with new user data
3	GET	/users/1	users	Retrieve user with id=1	200 OK with user data
4	PUT	/users/1	users	Update user with id=1	200 OK with updated data
5	DELETE	/users/1	users	Delete user with id=1	204 No Content
6	-	-	-	-	Request ends

💡 All requests target noun-based resource URLs; execution stops after response.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
HTTP Method	-	GET	POST	GET	PUT	DELETE	-
URL	-	/users	/users	/users/1	/users/1	/users/1	-
Resource Name	-	users	users	users	users	users	-
Response Status	-	200 OK	201 Created	200 OK	200 OK	204 No Content	-

Key Moments - 3 Insights

Why do we use nouns like '/users' instead of verbs like '/getUsers' in URLs?

Because REST APIs treat URLs as resources (things), not actions. Actions are expressed by HTTP methods (GET, POST, etc.). See execution_table rows 1 and 2 where GET and POST act on the noun 'users'.

How does the server know what action to perform if the URL is just a noun?

The HTTP method tells the server the action (GET to read, POST to create, etc.). The URL identifies the resource. This is shown in execution_table where the same URL '/users' is used with different methods.

What happens if we add an ID after the noun, like '/users/1'?

It specifies a single resource instance. The server performs actions on that specific user. See execution_table rows 3-5 for examples.

Visual Quiz - 3 Questions

Look at the execution_table, what HTTP method is used to update a user?

A GET

B PUT

C POST

D DELETE

💡 Hint

Check the 'HTTP Method' column in execution_table row 4.

At which step does the server respond with '201 Created'?

A Step 2

B Step 1

C Step 3

D Step 5

💡 Hint

Look at the 'Response' column in execution_table row 2.

If the URL changed from '/users' to '/getUsers', what principle would this break?

A Using HTTP methods for actions

B Using verbs for resource naming

C Using nouns for resource naming

D Using query parameters

💡 Hint

Refer to key_moments question about noun vs verb naming.

Concept Snapshot

Use nouns to name resources in URLs (e.g., /users).
Use HTTP methods (GET, POST, PUT, DELETE) to specify actions.
Add resource IDs to target specific items (e.g., /users/1).
Avoid verbs in URLs; keep URLs simple and resource-focused.
This makes APIs clear, consistent, and easy to use.

Full Transcript

In REST APIs, resource URLs should be named using nouns that represent the resource, like '/users'. The HTTP method (GET, POST, PUT, DELETE) tells the server what action to perform on that resource. For example, GET /users retrieves a list of users, POST /users creates a new user, and GET /users/1 retrieves a specific user by ID. This approach keeps URLs simple and focused on resources, while actions are handled by HTTP methods. Using verbs in URLs like '/getUsers' is discouraged because it mixes resource naming with actions. This visual trace showed each step of requests and responses, how variables like HTTP method and URL change, and clarified common confusions about noun-based resource naming.