REST Resources and URI Design – Java Backend Interview
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
A REST resource is something the API identifies and lets a client work with. It may be one order, the collection of orders, an invoice, or a checkout that is still in progress. The resource is the public concept; it does not have to be one Java object or one database row.
A URI identifies that resource, and the HTTP method explains the request. /orders commonly identifies the collection, while /orders/42 identifies one order. GET /orders/42 asks for a representation of the order. DELETE /orders/42 asks the server to remove the mapping or resource, according to the API's rules. The same URI can keep working after the server renames a controller or changes its storage.
Paths should show useful identity and relationships. /customers/7/orders is clear when the client needs the order collection for customer 7. If order 42 already has its own identity, /orders/42 is usually the simpler main address. A common API convention uses the query component to select a collection view: /orders?status=pending&sort=-createdAt&limit=20 asks for pending orders in a particular order and size. The whole path-and-query combination identifies that view; REST does not prescribe these parameter names.
Good URIs use familiar domain names and avoid internals such as /OrderController/findById/42 or /order_table/42. After POST /orders creates an order, the server can return 201 Created with Location: /orders/43. Noun-based, plural paths are useful conventions, but REST does not require that exact spelling pattern. Stable identity and correct message semantics matter more.
REST Resources and URI Design – Java Backend Interview
Direct Answer
A REST resource is something the API gives an identity, such as an order, customer, report, or collection. A URI identifies the resource, while JSON or another representation carries information about its state. Good URIs use stable domain names and do not expose controller methods or database tables.
Deep Dive & Architecture
Resource, identifier, and representation
These three words describe different things. The resource is the concept the API exposes, such as order 42. The URI /orders/42 identifies it. The representation is the data sent in a response or request, perhaps JSON containing the order's status and total. A resource can have more than one representation, and it does not need to match one database row.
A collection is also a resource. /orders can identify the collection even though its members change. A generated report, the current exchange rate, or a long-running export job can also be a resource when the API gives it an identity.
A small, stable URI vocabulary
Names should come from the business domain. A common design uses /orders for the collection and /orders/42 for one order. Nesting is useful when the parent genuinely explains the resource, as in /customers/7/orders. Deep paths should not repeat every relationship; if order 42 already has a stable address, clients should not need /regions/1/customers/7/orders/42 to reach it.
The query component is part of the URI and helps identify the requested resource or view. In this lesson, /orders?status=pending&page=2 identifies a filtered, paged orders view: status filters it and page selects a page. Using filter, sort, search, and page parameters this way is a common API design convention, not a rule imposed by REST or RFC 3986. The API should document the available keys, defaults, and limits.
Public names and internal implementation
/OrderController/findById/42 copies Java names into the public contract, and /order_table/42 copies storage names. Both become misleading after a refactor. /orders/42 describes the stable concept instead, so controllers, services, tables, or events can change without forcing clients to change.
A newly created member
A client can send POST /orders with an order representation. When the request creates order 43, 201 Created tells the client that a resource was created and Location: /orders/43 identifies the primary new resource. Later requests use that member URI. This is a protocol behavior; plural nouns and lower-case paths remain design conventions chosen for consistency.
Code Example
Collection: /orders
One member: /orders/42
Related collection: /customers/7/orders
Filtered view: /orders?status=pending&limit=20
A complete create exchange identifies the new member:
POST /orders HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"customerId":7,"items":[{"sku":"KB-1","quantity":1}]}
HTTP/1.1 201 Created
Location: /orders/43
Content-Type: application/json
{"id":43,"customerId":7,"status":"PENDING"}
Check your understanding
Answer these without looking back at the article.
- What is the difference between a resource and a representation?
- When is a nested URI helpful?
- Are noun-only paths a formal REST constraint?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.