Resources and Verbs

lesson 4-1 · ~10 min · 11/29

Quiz

Warm-up from lesson 3-2. In the pattern /users/:id, what does :id do?

REST in one paragraph

REST is a set of conventions for shaping an API around resources: the nouns of your system (users, orders, posts). Each resource collection gets a URL, and the HTTP method supplies the verb. You never invent action names like /createUser, the method already says it.

Intent	Method + path	Success code
list users	`GET /users`	200
read one	`GET /users/42`	200
create	`POST /users`	201
replace / update	`PUT /users/42` or `PATCH /users/42`	200
delete	`DELETE /users/42`	204

Five operations, two URL shapes (/users and /users/:id). Every resource in your API repeats this exact grid, which is why developers can guess a well-designed REST API without reading its docs.

Code exercise · javascript

Your turn. Complete endpoint(action, resource, id) so it produces the conventional method and path for each action. "list" and "create" are done, add "get", "update" (use PUT), and "remove".

Anatomy of a REST URL: nouns in the path identify things, the query string refines the question.

URL design rules

The conventions that make an API guessable:

Plural nouns: /users, not /user or /userList.
No verbs in paths: the method is the verb. POST /users beats /createUser.
Nest for ownership: /users/7/posts reads as "the posts of user 7". Keep nesting shallow (one level is usually plenty).
Query string for options: filtering, sorting, and paging are refinements of a GET, so they go after ?: /posts?status=draft&sort=newest.
Lowercase, hyphens if needed: /blog-posts, never /BlogPosts.

An API that follows these reads like a sentence: GET /users/7/posts?status=draft is "get user 7's draft posts".

Problem

A teammate designed the endpoint GET /getUserPosts?user=7. Redesign the path portion in proper REST style (nested resource, no verbs, no query string needed). Answer with just the path, starting with /.