REST is constraints, not JSON over HTTP: address resources, let methods decide the action, send hypermedia links to what's next and more.
For this question · chapter 2 of 3Watch three action endpoints become GET, PUT, DELETE on one address, /users/123. The method carries the action.
2/3Six endpoints become four addresses
Six endpoints become four addresses
What does 'the uniform interface' mean. The six POST endpoints on the left are each named after an action, so this API ignores the uniform interface. Every feature got its own name, which felt natural but has a cost - growing and unpredictable list of endpoint names.
Instead, name the thing and you got one address, /users/123. The three user endpoints become methods on that address: GET reads the user, PUT replaces the user, DELETE removes the user. Six endpoints will become three, all on that one address. The method specify the action, and the URL is the name of the resource.
The collection for the item is the same noun, plural - /users. Finding a user by email is not a different action. That search is a filter on the collection, GET /users?email=. The collection is just one address, and you can add as many filters later.
Orders belong to a user, so /users/123/orders sits one level under /users/123 and allows GET and POST actions. The path defines who owns what. The left column, the list of actions, is empty now. Every action has an address and a method.
But be careful of nesting. The path /users/123/orders/456/items/7 repeats ids that already identify things on their own. With nesting , it's important to know where to stop. An order has its own id, so /orders/456 stands alone and items sit under that path. So usually, nest one level to show ownership, and stop there.
The address tree should read like the domain: users have orders. And a client should be able to guess addresses that match your entities. A verb in a path means you are calling a function over HTTP, not addressing a resource.
Chapter 2 · step 1 of 6
What does 'the uniform interface' mean. The six POST endpoints on the left are each named after an action, so this API ignores the uniform interface. Every feature got its own name, which felt natural but has a cost - growing and unpredictable list of endpoint names.
Saved in this browser - sign in to keep your review list.
How should your speech become text?
Listening… your words appear above as you speak - tap Stop when you're done.
Recording · cr - tap Stop & transcribe when you're done.
Transcribing with AI…
Voice:
Keep going - a few more words and AI can grade it.
Interview lens
How interviewers actually use this question
Likely follow-ups
How would you model an action that isn't CRUD, like cancelling an order?Turn it into a state change or a noun, like PATCH on the order's status or POST to a cancellation sub-resource, and say why you picked one.
How deep would you nest resource URLs, and when would you flatten them?Nest for real ownership, usually one level. Anything with its own ID also gets a top-level path so clients don't need the parent.
Which HTTP methods apply to a collection like /users versus a single item like /users/123?GET and POST on the collection. GET, PUT, PATCH and DELETE on the item. The method carries the verb, so the path never needs one.
What's the difference between a resource and its representation?The resource is the concept. JSON or XML is one representation, picked with the Accept header, and its fields need not mirror your tables.
How would you let clients filter or search a collection without adding new paths?Use query parameters on the collection, like ?status=active&sort=-created_at, instead of paths such as /users/active.
What you can say
A resource is any piece of information the API can name and give an address to, like a user, an order, or a list of users.
The URL names the thing and the HTTP method says what to do with it, so I write GET /users, not /getUsers.
I use plural nouns everywhere, /users for the collection and /users/123 for one user, so every endpoint follows the same pattern.
Relationships show up in the path, so /users/123/orders/456 reads as order 456 belonging to user 123.
Good resources map to the business objects in your domain, with names clear enough that a client developer could guess the URL.
The limit is that not everything is a noun, so I model an action like cancelling an order as a state change, and I keep nesting to one or two levels.
Weak answers to avoid
Puts verbs in the URL/getUsers or /createOrder repeats what the HTTP method already says. Name the thing and let GET, POST and DELETE carry the action.
Lists naming rules but never says what a resource isPlural nouns and no verbs are style rules. Say first that a resource is a named, addressable thing, then give the rules as what follows from that.
Nests URLs as deep as the data model goes/users/1/orders/2/items/3/notes breaks when relationships change. Nest one level for ownership and give items with their own IDs a top-level path.
Treats the resource and its JSON as the same thingThe resource is the concept and JSON is one representation of it. Mentioning the Accept header shows you know the same resource can have several formats.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
