REST is an architectural style for designing networked applications. It stands for Representational State Transfer, emphasizing stateless communication and simplicity.

Key Principles:

• Stateless: Each request from a client to a server must contain all the information needed to understand and fulfill the request. The server doesn't store any information about the client state between requests.

• Client-Server: Separation of concerns between the client (user interface) and server (resources and business logic).

• Uniform Interface: A set of conventions, including resource identification, manipulation through representations, and self-descriptive messages.

• Resources: In REST, everything is a resource – an entity or concept. Resources are identified by URIs (Uniform Resource Identifiers).

HTTP Methods (Verbs):

• GET: Retrieve a representation of a resource.

• POST: Create a new resource.

• PUT: Update an existing resource or create a new one if it doesn't exist.

• DELETE: Remove a resource.

• PATCH: Partially update a resource.

Status Codes:

• 200 OK: Successful request.

• 201 Created: Resource created successfully.

• 204 No Content: Successful request; no additional information is needed to send back.

Statelessness:

• Each request from a client contains all the information the server needs.

• No client context is stored on the server between requests.

Example Scenario:

You have a web service for managing books.

• GET /books: Retrieve a list of all books.

• GET /books/1: Retrieve details of a specific book.

• POST /books: Create a new book.

• PUT /books/1: Update details of an existing book.

DELETE /books/1: Delete a book.

Request and Response:

• Request: Includes HTTP method, URI, headers, and often a body (for data).

• Response: Includes status code, headers, and a response body (for data) optionally.

Remember, REST is about simplicity and scalability.