Каковы основные принципы и ограничения REST архитектуры

А, ну вот, опять про эту вашу REST-архитектуру, блядь! Слушай, представляешь, это ж просто набор правил, как мудаки в интернете должны общаться, чтобы не переругаться нахуй. Типа свод законов для серверов и клиентов, чтобы не устроили бардак, как в той басне про лебедя, рака и щуку, только в рот меня чих-пых!

Вот смотри, основные принципы, на которых всё держится, как на трёх китах, только их пять, блядь:

1. Клиент и сервер — отдельные мудаки. Один (клиент) отвечает за то, чтобы красиво нарисовать кнопочки и поля ввода, а второй (сервер) — это такой складской хомяк, который данные хранит и обрабатывает. И живут они отдельно, чтобы один другому под ногами не путался и не орал «дай доступ к моей базе, сука!».

2. Никакой памяти, блядь! (Stateless). Это самое важное, ёпта! Каждый раз, когда клиент стучится к серверу, он должен принести с собой всю нужную инфу, как будто впервые пришёл. «Здрасьте, я Вася, вот мой пропуск, вот что я хочу». А сервер не должен помнить, был ли этот Вася тут пять секунд назад. Забыл — и хуй с ним! Зато так систему легче масштабировать — можно натыкать кучу одинаковых серверов, и им похуй, кто к кому обращался.

3. Кэширование — наше всё. Если сервер один раз ответил «список пользователей — Петя, Вася, Катя», он может сказать: «запомни этот ответ, мудила, на пять минут». И следующие пять минут клиент будет тыкаться в свою память, а не дергать сервер по каждому чиху. Производительность, блядь, растёт как на дрожжах!

4. Единый интерфейс — чтобы не выёбывались. Вот тут вся магия, блядь. Всё, с чем работаем, называется «ресурс» и имеет свой уникальный адрес (URI), типа /users/123. И взаимодействуем мы с ними через четыре священных глагола, которые все знают:

   • GET — «дай посмотреть» (получить инфу).
   • POST — «создай вот это» (добавить новый ресурс).
   • PUT — «перепиши всё нахуй» (полностью обновить).
   • DELETE — «удали это, чтоб я его не видел» (ну, ты понял).

5. Слоёный пирог (Layered System). Клиент вообще не должен париться, общается ли он напрямую с главным сервером или через кучу посредников — прокси, балансировщики, брандмауэры. Это как заказ еды: тебе похуй, сколько там курьеров её передавали, главное — чтобы пицца была горячая.

А вот тебе живой пример, как это выглядит в коде на FastAPI. Смотри, не отвлекайся!

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()

# Описываем, как выглядит наш ресурс "Пользователь"
class User(BaseModel):
    id: int
    name: str

# Имитируем "базу данных" — обычный словарь, блядь
db = {1: User(id=1, name="Alice")}

# Получить пользователя. Метод GET, адрес /users/{id}
@app.get("/users/{user_id}", response_model=User)
def get_user(user_id: int):
    user = db.get(user_id)
    if not user:
        # Если нет такого — отдаём стандартную HTTP-ошибку 404
        raise HTTPException(status_code=404, detail="User not found")
    return user  # Возвращаем представление ресурса (в JSON)

# Удалить пользователя. Метод DELETE, тот же адрес.
@app.delete("/users/{user_id}", status_code=204)
def delete_user(user_id: int):
    if user_id not in db:
        raise HTTPException(status_code=404, detail="User not found")
    del db[user_id]  # Просто выкидываем нахуй из словаря
    return  # Тело ответа пустое, статус 204 — «удалено, идите нахуй»

Вот и вся философия, блядь. Не государство придумали, а просто договорились общаться по-человечески, через адреса и глаголы. А то без этого — один сплошной пиздец и ругань в стиле «я тебе JSON отправил!» — «А я ждал XML, мудак!».