Uniform Interface Sub-Constraints
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Uniform interface is REST's shared interaction model for clients, servers, and intermediaries. Its four sub-constraints are identification of resources, manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state, usually shortened to HATEOAS. The shared model reduces coupling to server implementation, although it can be less specialized than a purpose-built RPC contract.
Resource identification means a URI such as /orders/42 identifies the order, not one JSON document, Java object, or database row. The same resource can have JSON, XML, or HTML representations selected through the request and response metadata. Stable identity lets the server change storage and lets clients request a suitable representation without creating a different resource for every format.
Manipulation through representations means the client sends a defined representation or change document instead of calling the server's internal object directly. A PUT representation can describe intended replacement state, while PATCH with Content-Type: application/merge-patch+json describes a merge patch. The representation is a public contract; authorization and domain rules still decide whether the requested transition is allowed.
A self-descriptive message contains enough standard and media-type information to interpret the exchange. The method and target express request intent, the status describes the outcome, headers carry metadata, and Content-Type defines the body format and semantics. This lets clients, caches, and gateways understand their part of the message without knowing the server's controller method or database model.
HATEOAS means a representation supplies links or controls for transitions available in the current state. A draft order may include a confirm relation, while a cancelled order omits it. The client understands the relation's meaning but obtains the current target from the response instead of hard-coding every URI template. HATEOAS is part of uniform interface, not the optional code-on-demand constraint, and it requires agreed media types and relation semantics.
Uniform Interface Sub-Constraints
Direct Answer
Uniform interface is REST's shared interaction model. It requires identification of resources, manipulation through representations, self-descriptive messages, and hypermedia as the engine of application state. Together they decouple clients from server implementation, although the generic interface can be less efficient than a purpose-built remote procedure call.
Deep Dive & Architecture
Resource identity remains stable across representations. /orders/42 can return JSON to an application and HTML to a browser without becoming two resources. Content negotiation and metadata identify the chosen representation. This separation lets the resource outlive one serialization format.
Manipulation through representations does not mean the server exposes its database row. The representation is a contract. PUT can convey intended target state, PATCH conveys changes under a patch media type, and POST submits content for resource-specific processing. Authorization and domain rules still decide whether a requested transition is allowed.
Self-description makes messages visible to generic components. Caches understand freshness fields, clients understand statuses, and converters understand media types. Application semantics still need registered or documented relation types and media contracts; a JSON object with undocumented magic fields is not self-explanatory merely because humans can read it.
Hypermedia moves state-transition knowledge into representations. A client knows what relation it wants, such as confirm, but obtains the current target from the server. This reduces coupling to route templates and lets available actions reflect resource state and permissions. The cost is richer media design and clients that understand relation semantics.
Code Example
HTTP/1.1 200 OK
Content-Type: application/hal+json
{
"id": 42,
"status": "draft",
"_links": {
"self": {"href": "/orders/42"},
"confirm": {"href": "/orders/42/confirmation"},
"customer": {"href": "/customers/7"}
}
}
The media type and relation names give the link structure meaning. A client selects the confirm relation when available rather than assuming every order has a hard-coded confirmation URI.
Check your understanding
Answer these without looking back at the article.
- Why is HATEOAS part of uniform interface rather than a separate optional constraint?
- How can one resource have several representations?
- What information makes an HTTP message self-descriptive?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.