Learn the IT-English conventions for naming REST resources: nouns vs verbs, collections, sub-resources and pluralisation.
0 / 18 completed
1 / 18
A reviewer says: 'Resource paths should be nouns, not verbs.' Which endpoint follows this convention?
REST resources are named with nouns (/users); the HTTP method (GET, POST) supplies the verb.
2 / 18
Which path correctly represents a 'sub-resource' (orders belonging to a user)?
Nesting expresses ownership: /users/42/orders means the orders that belong to user 42.
3 / 18
A guideline says collections should use 'plural nouns'. Which is correct?
Collections are plural (/products) and an item is addressed by ID within it (/products/123).
4 / 18
What is wrong with the endpoint POST /users/123/activate from a strict REST view?
Action-style verbs in paths deviate from resource-oriented design; state changes are often modelled as resource updates.
5 / 18
Which sentence correctly uses 'kebab-case' for a multi-word path segment?
Kebab-case (hyphen-separated lowercase) like /order-items is the common convention for readable URL segments.
6 / 18
Sarah: "Hey team, I'm reviewing this PR. The endpoint GET /products/details/456 is a bit clunky. It's better to use GET /product/456. We're exposing a resource, not a specific *action* on that resource."
This scenario highlights a common misunderstanding about RESTful API design. The core principle is to represent resources using nouns, not verbs. Using GET /products/details/456 implies an *action* (getting details) rather than the resource itself (the product). Sarah's comment correctly points out this mismatch, emphasizing that the endpoint should directly identify the product being accessed.
7 / 18
John is discussing the API design with his team. He notes that `GET /customers/orders/123` feels overly verbose and wants to refine it for better RESTful naming. Which of the following options would John likely propose as a more concise and appropriate endpoint, aligning with best practices for exposing resources?
John is correct in identifying the issue – using `GET /customers/orders/123` implies an action (retrieving orders) rather than exposing the resource itself. The best RESTful practice is to use a noun-based path segment for the resource and include identifiers as parameters, as demonstrated by GET /orders?customerId=123. Options A and B introduce unnecessary verbosity, while option C represents a different operation (creating an order) using `POST`.
8 / 18
Sarah: "Hey team, I'm reviewing this PR. The endpoint GET /products/details/456 is a bit clunky. It's better to use GET /product/456. We're exposing a resource, not a specific *action* on that resource."
This scenario highlights a common misunderstanding about RESTful API design. The core principle is to represent resources using nouns, not verbs. Using GET /products/details/456 implies an *action* (getting details) rather than the resource itself (the product). Sarah's comment correctly points out this mismatch, emphasizing that the endpoint should directly identify the product being accessed.
9 / 18
John is discussing the API design with his team. He notes that `GET /customers/orders/123` feels overly verbose and wants to refine it for better RESTful naming. Which of the following options would John likely propose as a more concise and appropriate endpoint, aligning with best practices for exposing resources?
John is correct in identifying the issue – using `GET /customers/orders/123` implies an action (retrieving orders) rather than exposing the resource itself. The best RESTful practice is to use a noun-based path segment for the resource and include identifiers as parameters, as demonstrated by GET /orders?customerId=123. Options A and B introduce unnecessary verbosity, while option C represents a different operation (creating an order) using `POST`.
10 / 18
Sarah: "Hey team, I'm reviewing this PR. The endpoint GET /products/details/456 is a bit clunky. It's better to use GET /product/456. We're exposing a resource, not a specific *action* on that resource."
This scenario highlights a common misunderstanding about RESTful API design. The core principle is to represent resources using nouns, not verbs. Using GET /products/details/456 implies an *action* (getting details) rather than the resource itself (the product). Sarah's comment correctly points out this mismatch, emphasizing that the endpoint should directly identify the product being accessed.
11 / 18
John is discussing the API design with his team. He notes that `GET /customers/orders/123` feels overly verbose and wants to refine it for better RESTful naming. Which of the following options would John likely propose as a more concise and appropriate endpoint, aligning with best practices for exposing resources?
John is correct in identifying the issue – using `GET /customers/orders/123` implies an action (retrieving orders) rather than exposing the resource itself. The best RESTful practice is to use a noun-based path segment for the resource and include identifiers as parameters, as demonstrated by GET /orders?customerId=123. Options A and B introduce unnecessary verbosity, while option C represents a different operation (creating an order) using `POST`.
12 / 18
Sarah: "Hey team, I'm reviewing this PR. The endpoint GET /products/details/456 is a bit clunky. It's better to use GET /product/456. We're exposing a resource, not a specific *action* on that resource."
This scenario highlights a common misunderstanding about RESTful API design. The core principle is to represent resources using nouns, not verbs. Using GET /products/details/456 implies an *action* (getting details) rather than the resource itself (the product). Sarah's comment correctly points out this mismatch, emphasizing that the endpoint should directly identify the product being accessed.
13 / 18
John is discussing the API design with his team. He notes that `GET /customers/orders/123` feels overly verbose and wants to refine it for better RESTful naming. Which of the following options would John likely propose as a more concise and appropriate endpoint, aligning with best practices for exposing resources?
John is correct in identifying the issue – using `GET /customers/orders/123` implies an action (retrieving orders) rather than exposing the resource itself. The best RESTful practice is to use a noun-based path segment for the resource and include identifiers as parameters, as demonstrated by GET /orders?customerId=123. Options A and B introduce unnecessary verbosity, while option C represents a different operation (creating an order) using `POST`.
14 / 18
During a code review, Alex comments: 'I'm not sure about this endpoint. Using GET /users/profile is a bit ambiguous. It suggests an action (getting the profile) rather than simply exposing the resource itself.' Which of the following RESTful naming conventions would be most appropriate in this scenario?
The key here is representing the resource itself. Using kebab-case for multi-word segments (/user/profile) clearly identifies that you're accessing a user's profile as a distinct resource. Options A and D introduce unnecessary verbosity by implying an action; option C uses an overly complex identifier.
15 / 18
You're designing an API for a blogging platform. The goal is to retrieve all comments associated with a specific blog post. Which of the following REST endpoint paths best represents this scenario?
The core principle of RESTful resource naming is to use nouns to represent resources. GET /posts/123/comments correctly identifies 'comments' as a sub-resource related to the blog post (/posts/123). Options B and C are incorrect because they include verbs, and option D represents creating a new resource, not retrieving existing ones.
16 / 18
A senior developer points out: 'Our API endpoints should consistently use plural nouns for collections. This aligns with REST principles and simplifies client-side development.' Which of the following endpoint names demonstrates this best practice?
Using plural nouns (/productCategories) indicates that you're interacting with a collection of product categories. This is standard REST practice for representing lists or groups of related resources. Options A and B are singular resource names, and option D represents a specific action (creating an order).
17 / 18
During a Slack discussion about API design, David says: 'I'm struggling with the endpoint POST /users/123/activate. It feels like we're trying to *do* something (activate) instead of simply exposing a resource.' What is the primary RESTful naming concern raised by David?
David's comment highlights the crucial distinction between exposing a resource and performing an action on that resource. The path /users/123/activate implies that you are *activating* a user, which is an operation. RESTful APIs should primarily expose resources using nouns in their paths.
18 / 18
You need to design an API endpoint for retrieving a single customer's order details. Which of the following path names would be most appropriate and adhere to RESTful naming conventions?
The correct path is /customerOrders/123. This uses kebab-case to represent the relationship between a customer and their orders (a sub-resource). Option A is too generic; option C reverses the resource relationship; and option D is overly verbose.
What will I practice in "REST Resource Naming Vocabulary"?
This is an API Design Language exercise set. It walks through 18 scenario-based multiple-choice questions built around real usage of API Design Language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 18 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the API Design Language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more API Design Language exercises?
See the API Design Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — API Design Language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.