Suggest an editImprove this articleRefine the answer for “What is REST?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**REST (Representational State Transfer)** is an **architectural style** for building networked applications and APIs that describes how a client and a server should interact over HTTP. In simple terms, it is a set of principles that make building an API convenient and clear. **Key point:** REST is not a protocol or a technology, it is a set of rules and approaches usually implemented on top of HTTP.Shown above the full answer for quick recall.Answer (EN)Image**REST (Representational State Transfer)** is an **architectural style** for building networked applications and APIs that describes **how a client and a server should interact over HTTP**. In simple terms: **REST is a set of principles that make building an API convenient and clear**. --- ## What matters to understand right away REST is **not a protocol** and **not a technology**. It is a set of **rules and approaches** that are usually implemented on top of **HTTP**. --- ## The core idea of REST REST is built around **resources**. - a resource is an object or entity (a user, an order, a product) - a resource has a **URL** - actions are performed on a resource through **HTTP methods** Example: - `/users/1` - a user - GET - retrieve - POST - create - PUT / PATCH - update - DELETE - delete --- ## The main principles of REST (in plain terms) ### 1. Client-server - the client and server are separated - the client is responsible for the interface - the server is responsible for data and logic They can be developed independently. --- ### 2. Stateless - the server **does not store the client's state** - each request contains all the needed information We already covered this, it is a key principle of REST. --- ### 3. Resources and URLs - everything is a resource - each resource has a **unique URL** - the URL describes **what**, not **how** `/getUser?id=1` is bad `/users/1` is good --- ### 4. Using HTTP methods as intended - GET - retrieve - POST - create - PUT - replace - PATCH - update - DELETE - delete This makes the API predictable. --- ### 5. Using HTTP statuses - 200 - success - 404 - not found - 401 - no access - 500 - server error The client **understands the result without parsing text**. --- ### 6. Uniform interface - the same rules for all resources - the same response formats (often JSON) The API is easier to learn and use. --- ## REST in practice (an example) Request: ``` GET /users/1 ``` Response: ```json { "id": 1, "name": "Alice" } ``` Clear even without documentation: - what we're doing - with what - what the result is --- ## REST ≠ REST API (a common mistake) - **REST** is an architectural style - **REST API** is an API built according to REST's principles Most "REST APIs" in practice are **REST-like**, but that is enough. --- ## Real-life example REST is like a store with rules: - the address is where the item is - the method is what you want to do - the response is the result (success or an error) Everyone knows the rules, there is no confusion. --- ## Short answer for an interview Remember this wording: > **REST is an architectural style for client-server application interaction, based on working with resources over HTTP, using standard methods, a stateless approach, and HTTP response codes.**For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.