Какова разница между HTTP и REST?

Так, слушай сюда, про HTTP и REST, а то я вижу у тебя глаза стекленеют, как у Герасима из "Муму", когда ему про собаку объясняли.

Ну, HTTP, блядь — это как правила дорожного движения, но для интернета. Представь себе почтальона Печкина, ёпта. Он приходит к тебе (клиент), ты ему говоришь: "Печкин, принеси-ка мне посылку с таким-то номером (GET запрос)". Он бежит на почту (сервер), ищет, находит, приносит и говорит: "Вот, держи, 200 OK, всё в порядке". А если посылки нет, он такой: "404, мудила, не найдено, иди нахуй". Вот и весь протокол. Просто договорённость, как один комп просит у другого данные, а тот отвечает. Без сохранения состояния, то есть Печкин каждый раз тебя заново не узнаёт — ты ему каждый раз говоришь, кто ты и что тебе надо.

А теперь, сука, REST. Это уже не просто правила, а целая философия, архитектурный стиль, блядь! Это когда ты берёшь этого самого HTTP-Печкина и заставляешь его работать по чёткой, красивой системе. Не просто "принеси что-нибудь", а по принципам.

Смотри, основные принципы REST, это как заповеди, блядь:

1. Клиент-сервер. Чёткое разделение: ты — клиент (браузер или приложение), он — сервер. Каждый занимается своим делом, не лезет в чужой огород.
2. Stateless (без состояния). Это как в том анекдоте: "Я тебя вчера видел?" — "Нет". — "И я нет". Каждый запрос самодостаточен. Сервер не помнит, кто ты и что ты у него просил пять минут назад. Всё, что нужно, ты тащишь в запросе сам, как улитка свой домик.
3. Кэшируемость. Ответы сервера можно кэшировать, чтобы не дергать его по пустякам. Как будто Печкин оставил тебе газету в ящике, и ты неделю её оттуда достаёшь, пока новый номер не придёт.
4. Единообразие интерфейса. Вот тут, блядь, самое сокровенное! Всё строится вокруг ресурсов (пользователи, задачи, котики), у каждого есть свой уникальный адрес (URL). И управляешь ты ими строго через HTTP-глаголы:
   • GET /tasks — дай список всех задач (посмотри).
   • GET /tasks/5 — дай конкретно задачу номер пять (посмотри одну).
   • POST /tasks — создай новую задачу (роди).
   • PUT /tasks/5 — обнови задачу номер пять полностью (перепиши).
   • PATCH /tasks/5 — обнови задачу номер пять частично (подправь).
   • DELETE /tasks/5 — удали задачу номер пять (уебей). Красиво, логично, как в армии: каждому действию — свой глагол.
5. Многослойность. Клиенту похуй, с кем он общается. Может, прямо с сервером, а может, через десять прокси, балансировщиков и фаерволлов. Ему главное — получить ответ.
6. HATEOAS (код по требованию, опционально). Это уже высший пилотаж, когда в ответе сервер не только данные шлёт, но и ссылки "а теперь ты можешь сделать вот это и вот это". Как меню в ресторане. Но его часто, блядь, игнорируют, потому что заебись.

Короче, разница проще пареной репы:

• HTTP — это инструмент, молоток и гвозди.
• REST — это чертёж и стиль, по которому ты этим молотком строишь дом, а не просто колотишь по всему подряд, пока пальцы не отобьёшь.

Все REST-сервисы используют HTTP, но не всякий сервис на HTTP — RESTful. Если ты просто GET и POST на всё подряд кидаешь, а про ресурсы и глаголы не слышал — это не REST, а так, HTTP-говносервис.

Вот, смотри, как это выглядит в коде, на примере списка дел (Flask). Блок кода не трогаю, как договаривались, но поясню суть:

from flask import Flask, jsonify, request

app = Flask(__name__)

tasks = [
    {"id": 1, "title": "Изучить REST API", "done": False},
    {"id": 2, "title": "Написать документацию", "done": True}
]
next_id = 3

# GET /tasks - получить ВСЕ задачи (ресурс 'tasks')
@app.route('/tasks', methods=['GET'])
def get_tasks():
    return jsonify({"tasks": tasks})

# GET /tasks/1 - получить ОДНУ задачу (конкретный ресурс)
@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:
        return jsonify({"task": task})
    return jsonify({"message": "Задача не найдена"}), 404 # Статус, ёпта!

# POST /tasks - СОЗДАТЬ новую задачу (новый ресурс в коллекции)
@app.route('/tasks', methods=['POST'])
def create_task():
    global next_id
    if not request.json or not 'title' in request.json:
        return jsonify({"message": "Отсутствует 'title' в запросе"}), 400
    new_task = {
        'id': next_id,
        'title': request.json['title'],
        'done': request.json.get('done', False)
    }
    tasks.append(new_task)
    next_id += 1
    return jsonify({"task": new_task}), 201 # 201 Created - родил!

# PUT /tasks/1 - ОБНОВИТЬ задачу целиком
@app.route('/tasks/<int:task_id>', methods=['PUT'])
def update_task(task_id):
    task = next((t for t in tasks if t['id'] == task_id), None)
    if not task:
        return jsonify({"message": "Задача не найдена"}), 404
    if not request.json:
        return jsonify({"message": "Пустой запрос"}), 400

    task['title'] = request.json.get('title', task['title'])
    task['done'] = request.json.get('done', task['done'])
    return jsonify({"task": task})

# DELETE /tasks/1 - УДАЛИТЬ задачу (ресурс)
@app.route('/tasks/<int:task_id>', methods=['DELETE'])
def delete_task(task_id):
    global tasks
    initial_len = len(tasks)
    tasks = [t for t in tasks if t['id'] != task_id]
    if len(tasks) < initial_len:
        return jsonify({"message": "Задача удалена"}), 200
    return jsonify({"message": "Задача не найдена"}), 404

if __name__ == '__main__':
    app.run(debug=True)

Видишь? Всё по канону. Адрес (/tasks) — это ресурс. Методы HTTP (GET, POST, PUT, DELETE) — это действия над ним. Статусы (200, 404, 201) — это ответ "получилось/не получилось". Вот это и есть RESTful API, блядь, когда всё на своих местах и логично, как в хорошем конструкторе. А не то что некоторые творят — один POST на все случаи жизни, будто им в рот чих-пых!