Представь, что на районе все хотят друг с другом общаться: кто-то спрашивает, где купить семки, кто-то хочет узнать, когда следующая сходка. Но, чтобы не было бардака, все договариваются о чётких правилах. Эти правила — это и есть REST (Representational State Transfer). Он говорит, как правильно общаться, чтобы все понимали друг друга.
Как это работает?
REST — это стиль общения, который используется, когда твои приложения (например, сайт и сервер) общаются. Это как базар между пацанами, только вместо слов используют HTTP-запросы, такие как GET, POST, PUT, DELETE. Каждая команда говорит серверу, что от него хотят.
Представь, что ты хозяин ларька на районе. К тебе подходят разные чуваки и говорят:
GET: "Дай посмотреть, что у тебя на витрине!"
Ты им показываешь список семок, пива и жвачки. Это значит, что ты даёшь инфу, ничего не меняя.
POST: "Я хочу купить семки!"
Это как добавление чего-то нового: чувак приносит бабки, а ты даёшь ему семки.
PUT: "Слушай, а давай я поменяю пиво на жвачку!"
Это значит обновить что-то, заменить старую вещь на новую.
DELETE: "Убери мои жвачки из корзины, я их не хочу."
Тут понятно — удалить ненужное.
PATCH:
"Слышь, братан, я тут у себя в заказе одну мелочь хочу поменять."
Это как сказать серверу: "Обнови только часть информации." Например, ты заказал пиво и семки, а потом решил поменять только количество пива.
HEAD:
"Чувак, скажи, есть ли у тебя товар, но инфу мне всю не давай."
Это как GET, только сервер отвечает без данных — он просто говорит, доступен ли ресурс или нет. Например, сайт проверяет: "Есть ли на сервере страница про пиво?" Сервер отвечает: "Да, есть." Но не рассказывает про пиво ничего.
OPTIONS:
"Эй, какие у вас тут правила?"
Это запрос, чтобы узнать, что можно делать с ресурсом. Например, ты спрашиваешь сервер: "Можно ли тут заказывать или удалять что-то?" А он отвечает: "У нас доступны GET, POST и DELETE."
Архитектурные правила REST
Чтобы твой API был реально крутым, как порядок на районе, нужно соблюдать несколько правил:
Клиент-Серверная модель
Клиент (например, сайт или приложение) отправляет запросы, сервер отвечает. У каждого своя зона ответственности. Клиент только спрашивает, сервер только отвечает — как базар без перебивания.
Отсутствие состояния (stateless)
Сервер не помнит, что было раньше. Каждый запрос — как новое общение. Например, если ты заказал семки, сервер не будет помнить, что ты до этого просил пиво, пока ты ему об этом не скажешь.
Единообразие интерфейса
Всё работает по единому плану. Если ты делаешь GET /users, ты должен получить список юзеров. Если делаешь DELETE /users/123, этот юзер будет удалён. Никаких сюрпризов.
Кэширование
Сервер может говорить клиенту: "Эту инфу можно запомнить, чтобы не спрашивать заново." Например, список товаров обновляется редко, и сервер говорит: "Кэшируй это на 5 минут."
Многоуровневая система
Сервер может использовать другие серверы для выполнения запросов, но клиент об этом не должен знать. Это как если твой кореш на районе перепоручает мелкие дела другим, а ты общаешься только с ним.
Код по запросу (опционально)
Иногда сервер может отправлять клиенту код (например, скрипты), который тот будет выполнять.
Какие данные передаются?
REST работает с разными типами данных, но чаще всего используются:
JSON — как разговор на пацанском, простой и понятный.
Пример:
{
"имя": "Вася",
"товар": "семки",
"количество": 2
}
XML — более старый и строгий формат, но сложнее, как разговор с ботаником.
Пример:
<заказ>
<имя>Вася</имя>
<товар>семки</товар>
<количество>2</количество>
</заказ>
Текст/HTML — используется реже, когда нужно просто вернуть текст или веб-страницу.
Как правильно проектировать REST API?
Продумай ресурсы
Всё в REST — это ресурс. Например:
- Пользователи (/users)
- Товары (/products)
- Заказы (/orders)
Используй правильные HTTP-методы
- GET — чтобы получать данные.
- POST — чтобы добавлять новые записи.
- PUT — чтобы заменять данные полностью.
- PATCH — чтобы менять только часть данных.
- DELETE — чтобы удалять данные.
Делай понятные эндпоинты
Никаких сложных адресов!
- Вместо /getUsers - лучше /users.
- Вместо /deleteUserById?id=123 - лучше /users/123.
Не вкладывай лишние действия в эндпоинты
Всё должно быть про ресурс. Вместо /users/123/delete - используй DELETE /users/123.
Добавляй версии API
Если твой API будет обновляться, делай версии.
Например:
- /v1/users
- /v2/users
Документируй API
Напиши, как твоё API работает, чтобы другие пацаны на районе знали, как им пользоваться. Для этого можно использовать Swagger.
Пример API для магазина семок
Эндпоинты:
GET /products — получить список товаров.
Ответ:
[
{"id": 1, "name": "семки", "price": 10},
{"id": 2, "name": "пиво", "price": 50}
]
POST /orders — создать заказ.
Запрос:
{
"product_id": 1,
"quantity": 3
}
Ответ:
{"id": 123, "status": "created"}
PATCH /orders/123 — обновить заказ (например, изменить количество).
Запрос:
{"quantity": 5}
DELETE /orders/123 — удалить заказ.
Подпишись на наш телеграм канал, чтобы узнать больше: t.me/it_for_dudes