REST: the naming conventions

You already know REST

Here's the thing: everything you've done in this course so far? That was REST.

Every URL you called (/users, /users/1, /products), every method you used (GET, POST, PUT, DELETE), every JSON response you read. All of it follows a set of conventions called REST (Representational State Transfer).

REST isn't a technology. It's not a protocol. It's a style guide. A set of naming conventions that most APIs follow so that developers (and now you) can predict how an API works without memorizing every endpoint.

---

The two URL patterns

REST boils down to two URL patterns. Just two:

Pattern 1: the collection. /users, /products, /orders. This points to the whole table. All users, all products, all orders.

Pattern 2: a specific item. /users/1, /products/42, /orders/789. This points to one row in the table, identified by its ID.

That's the foundation. Everything else in REST is built on top of these two patterns.

---

The full CRUD matrix

Combine the two URL patterns with the four HTTP methods, and you get the complete playbook:

Five lines. That's the entire REST playbook for any resource. If you know the resource name, you know the endpoints.

Notice the logic: POST goes to the collection (/products) because you're adding to the group. PUT and DELETE go to a specific item (/products/42) because you're changing or removing one particular row.

---

Predictability is the point

The whole reason REST conventions exist is predictability. If an API has a /users endpoint, you can guess:

• GET /users gives you a list of users
• GET /users/5 gives you user #5
• POST /users creates a new user
• PUT /users/5 updates user #5
• DELETE /users/5 removes user #5

You don't need to read the docs to guess this. That's the power of conventions. It's like driving in a new city: you've never been there, but you know red means stop and green means go.

Let's verify. DummyJSON follows REST conventions. Try getting the list of products:

Now a specific product by ID:

Same base URL, same resource name. The pattern works exactly as you'd expect.

---

The naming rules

REST has a few naming conventions that keep things consistent:

Use plural nouns. /users, not /user. /products, not /product. The endpoint represents the collection (the table), and tables hold many items.

Use nouns, not verbs. The URL describes what you're working with, not what you're doing. The HTTP method handles the action.

The first one is RESTful. The method (DELETE) says what to do, the path (/users/42) says what to do it to. Clean separation.

The second one bakes the action into the URL. That's redundant and breaks the convention. If you see URLs like /createUser or /deleteProduct/42 in an API, that API isn't following REST conventions.

Keep URLs lowercase. /users/42, not /Users/42.

---

What "RESTful" means

You'll hear engineers say "our API is RESTful" or "this isn't very RESTful." Now you know what they mean.

RESTful = the API follows REST conventions. Plural nouns in URLs, standard HTTP methods for CRUD, predictable URL patterns. It doesn't mean the API is perfect or powerful. It means it follows the style guide.

Most APIs you'll work with are RESTful. Some aren't (GraphQL is a different approach, for example). But REST is the default, the lingua franca. It's what engineers assume unless told otherwise.

---

Key takeaways

• REST is a set of naming conventions, not a technology
• Two URL patterns: /things (collection) and /things/id (specific item)
• Combine them with GET, POST, PUT, DELETE to get the full CRUD playbook
• URLs use plural nouns (/users, not /user) and no verbs (DELETE /users/42, not POST /users/42/delete)
• RESTful means the API follows these conventions. Most APIs do