Каковы основные принципы архитектурного стиля REST для веб-приложений?

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

Представь себе, что ты заходишь в библиотеку, блядь. Ты — клиент, библиотека — сервер. Это и есть первый принцип, клиент-серверная архитектура. Ты не таскаешь с собой все книги мира, они лежат там, у них. И ты можешь приходить туда с любого устройства — с телефона, с ноута, хоть с умного холодильника, если он умеет HTTP-запросы слать.

Теперь самое важное: Stateless, или «без состояния». Это значит, что библиотекарь, сука, тебя не помнит! Ты приходишь, говоришь: «Дайте книгу про то, как правильно ебашить REST API». Он тебе даёт. Ты уходишь. Завтра приходишь — он смотрит на тебя как на нового клиента. Ему похуй, что ты вчера был. Каждый твой запрос должен содержать ВСЁ, что нужно: «Я — Вася, мой читательский билет — 12345, хочу эту книгу». Сервер не хранит у себя в голове, что Вася вчера уже брал «Муму» Тургенева. Это, с одной стороны, охуенно для масштабирования — можно нанять сто таких забывчивых библиотекарей, и любой из них тебя обслужит. С другой — иногда неудобно, но так надо, блядь.

Кэшируемость — это когда ты взял книгу, прочитал, а потом твой друг спрашивает про то же самое. Ты ему можешь сразу рассказать, не бегая в библиотеку снова. Или библиотекарь может поставить на полку копию популярной книги, чтобы быстрее выдавать. В HTTP это вот эти вот заголовки Cache-Control, которые говорят, сколько ответ можно хранить у себя в загашнике.

А теперь, внимание, единообразный интерфейс — это святое, ёпта! Всё строится вокруг ресурсов. Что такое ресурс? Да всё, что угодно! Задача, пользователь, котик, заказ — всё это ресурс. И каждый ресурс имеет свой уникальный адрес (URI), как домашний адрес. /tasks, /users/123, /cats/fluffy.

И работаем мы с ними через 4 основных глагола, которые все знают:

• GET — посмотреть (получить книгу с полки).
• POST — создать (сдать в библиотеку свою новую книжку).
• PUT/PATCH — обновить (исправить опечатку в уже существующей книге).
• DELETE — удалить (списать старую, истрепанную книгу в утиль).

И последняя крутая штука в этом принципе — HATEOAS (Hypermedia as the Engine of Application State). Это когда сервер, отвечая тебе, не просто скидывает голые данные, а ещё и прикладывает ссылочки, что можно сделать дальше. Типа: «Вот тебе список задач. А если хочешь посмотреть детали первой — вот тебе ссылка href: "/tasks/1". Хочешь создать новую — вот тебе ссылка href: "/tasks", метод POST». Клиент как слепой котёнок, тыкается в эти ссылки и так всё приложение и исследует. Красота, блядь!

Многослойная система — это когда между тобой и главным сервером может стоять куча всякого: прокси, фаерволы, балансировщики нагрузки. Ты об этом даже не узнаешь. Для тебя это одна точка входа. А они там внутри решают, на какой конкретный сервер твой запрос отправить.

Ну и Code-On-Demand — это как опциональная приблуда. Сервер может сказать: «О, чувак, чтобы отобразить эту хрень, тебе нужен вот этот скриптик, держи». Как JavaScript в браузер. Но это необязательно, многие API без этого живут.

Теперь смотри на код, тут всё по канону:

from flask import Flask, jsonify, request, url_for

app = Flask(__name__)

tasks = [
    {'id': 1, 'title': 'Learn REST', 'done': False},
    {'id': 2, 'title': 'Build API', 'done': True}
]

@app.route('/tasks', methods=['GET'])
def get_tasks():
    # HATEOAS: добавление ссылок на отдельные ресурсы
    task_list = []
    for task in tasks:
        task_data = task.copy()
        task_data['uri'] = url_for('get_task', task_id=task['id'], _external=True)
        task_list.append(task_data)
    return jsonify({'tasks': task_list})

@app.route('/tasks/<int:task_id>', methods=['GET'])
def get_task(task_id):
    task = next((t for t in tasks if t['id'] == task_id), None)
    if task is None:
        return jsonify({'error': 'Task not found'}), 404
    return jsonify(task)

@app.route('/tasks', methods=['POST'])
def create_task():
    if not request.json or 'title' not in request.json:
        return jsonify({'error': 'Missing title'}), 400
    task = {
        'id': tasks[-1]['id'] + 1 if tasks else 1,
        'title': request.json['title'],
        'done': request.json.get('done', False)
    }
    tasks.append(task)
    return jsonify(task), 201 # 201 Created

Видишь? GET /tasks — получил все задачи, да ещё с ссылками (HATEOAS!). GET /tasks/1 — получил конкретную. POST /tasks — создал новую. Stateless — никаких сессий, в рот меня чих-пых. Всё по феншую.

Итог, почему это овердохуище:

• Проще пареной репы: Используешь HTTP, который уже везде есть. Не надо изобретать свои протоколы, как некоторые умники.
• Масштабируется на раз-два: Без состояния — значит, можно серверов натыкать сколько влезет.
• Свобода: Клиент на чём хочешь пиши, сервер на чём хочешь. Главное — JSON по HTTP гонять.
• Гибкость: Захотели поле новое в ответ добавить — добавили. Старые клиенты не сломаются, они просто проигнорируют то, чего не ждали.

Вот и вся магия, блядь. Не ракетостроение, а очень удобная и логичная штука, если, конечно, не выёбываться и делать её по уму.