Что такое REST (архитектурный стиль) и его ключевые принципы?

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

Представь себе, что у тебя есть склад, нахуй. Огромный такой склад, где всё лежит по полочкам. Вот REST — это и есть правила, как с этим складом общаться, чтобы не превратиться в обосранного идиота, который всё перевернёт.

Шесть главных правил, хуле:

1. Единый интерфейс, блядь (Uniform Interface): Тут всё просто, как три копейки. Каждая вещь на складе — это ресурс, и у неё есть свой уникальный адрес, типа /api/табуретки/5. Хочешь что-то сделать? Используй стандартные команды: посмотреть (GET), положить новое (POST), заменить всё (PUT), подправить чутка (PATCH) или выкинуть нахуй (DELETE). Идея в том, что в каждом запросе и ответе есть всё, что нужно, чтобы понять, что происходит. А ещё, если очень хочется, можно в ответ впихнуть ссылки на то, что можно сделать дальше (это HATEOAS, но его часто забивают хуй, честно говоря).
2. Без состояния, сука (Stateless): Это самое важное, ёбана! Каждый твой приход на склад — это отдельная история. Ты говоришь: «Дай мне табуретку номер пять и вот мой пропуск». И всё. Склад тебя не помнит с прошлого раза, он не хранит у себя в голове, что ты вчера приходил за гвоздями. Каждый раз начинаем с чистого листа. Так проще масштабировать, блядь, можно кучу одинаковых складов наставить.
3. Кэширование, ёпта (Cacheable): Ну ты же не будешь каждый раз бегать смотреть, не украли ли ту же самую табуретку? Если склад говорит: «Табуретка цела, можешь не проверять час», — ты и не проверяешь. Ответы должны чётко говорить, можно ли их запомнить и не спрашивать одно и то же каждые пять секунд.
4. Клиент и сервер отдельно (Client-Server): Это как разделение властей, блядь. Твой телефон или браузер (клиент) — это одно. А склад с API (сервер) — это другое. Они общаются по чёткому протоколу и не лезут в дела друг друга. Клиент не знает, как склад устроен внутри, а склад не парится, какое у клиента приложение.
5. Многослойность (Layered System): Между тобой и складом может быть куча посредников: охранник на проходной (прокси), диспетчер, который решает, на какой из десяти одинаковых складов тебя отправить (балансировщик). Тебе, как клиенту, похуй на эту кухню. Ты общаешься с «фасадом», а они там сами разбираются.
6. Код по требованию (Code on Demand, опционально): Это как если бы склад, кроме табуретки, приложил бы к ней инструкцию по сборке на JavaScript. В вебе это обычное дело — сервер присылает скрипты, которые выполняются в браузере. Но в чистом API это редкость, так что можно про это правило вспоминать раз в год.

Ну и пример, чтобы не быть пиздаболом:

Ты шлёшь на склад записку (запрос):

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <token>

По смыслу это: «Эй, склад! Дай-ка мне (GET) данные о пользователе (/api/users/) под номером 42. Я понимаю JSON (Accept), и вот мой пропуск (Authorization), не гони пизду!».

Склад тебе отвечает:

{
  "id": 42,
  "name": "Alice",
  "email": "alice@example.com",
  "_links": {
    "self": { "href": "/api/users/42" },
    "orders": { "href": "/api/users/42/orders" }
  }
}

Вот, блядь, держи свою Алису. А эти _links — это намёк, мол, раз уж ты здесь, можешь ещё и заказы этой Алисы посмотреть по ссылке orders. HATEOAS, мать его, в действии.

Вот и вся магия, ёпта. Ничего сверхъестественного, просто правила, чтобы не устраивать бардак. Хотя, конечно, в реальности половина этих правил благополучно игнорируется, и получается не REST, а REST-in-peace, но это уже другая, пиздецкая история.