ByteByteGo (проект Алекса Сюя, автора System Design Interview) прислал шпаргалку по основным принципам REST API.
Разрешение, правда маловато, так что продублирую текстом. Вот что они считают главным в REST:
1️⃣ Клиент-сервер. Причем понимают это как разделение пользовательского интерфейса и хранения/процессинга данных. Что, в свою очередь, обеспечивает масштабирование и переносимость.
2️⃣ Отсутствие состояния. В каждом запросе клиент отправляет всю необходимую для обработки информацию, состояние сессии не хранится на сервере.
3️⃣ Кэширование. Ответ сервера может быть в явном виде помечен как кэшируемый или некэшируемый, что позволяет клиенту оптимизировать число перезапросов.
4️⃣ Слоистая система. Для клиента прозрачна, а на стороне сервера позволяет организовать промежуточные слои — для безопасности, балансировки, изолирования реальной архитектуры обработки и хранения и т.п.
5️⃣ Код по запросу. Сервер может передавать клиенту программный код для обработки или представления данных, таким образом расширяя возможности клиента и добавляя гибкости.
6️⃣ Стандартизированный интерфейс: понятно, как строить запрос.
Элементы запроса:
🔹Глагол http (GET, POST, PUT, PATCH, DELETE)
🔹Протокол (всегда HTTPS://)
🔸Субдомен для API
🔸Версия (/v1)
🔸Эндпоинт — имя ресурса (существительное)
🔹Параметры фильтрации
🔹Параметры пагинации (page, limit)
А теперь проверьте себя — используете ли вы эти возможности в своих "REST API", или вы просто JSON'ы кидаете через HTTP? 😉
Разрешение, правда маловато, так что продублирую текстом. Вот что они считают главным в REST:
Элементы запроса:
🔹Глагол http (GET, POST, PUT, PATCH, DELETE)
🔹Протокол (всегда HTTPS://)
🔸Субдомен для API
🔸Версия (/v1)
🔸Эндпоинт — имя ресурса (существительное)
🔹Параметры фильтрации
🔹Параметры пагинации (page, limit)
А теперь проверьте себя — используете ли вы эти возможности в своих "REST API", или вы просто JSON'ы кидаете через HTTP? 😉