Привет! Эта статья на холиварную тему. Комментарии приветствуются, особенно если у вас есть интересный опыт, которым можете поделиться!
Проектирование REST API - это процесс создания дизайна методов обмена данными. Дизайн - это субъективное. У одних "так", у других "сяк". А кто прав? Иногда все, а иногда нет.

В этой статье Системные аналитики, Backend-разработчики и Архитекторы найдут спорные вопросы с проектов и собеседований, которые связаны с созданием контрактов REST API.
Вопросы взяла по итогам общения с системными аналитиками, которые недавно проходили собеседования, с моего открытого вебинара, и из комментариев к серии постов про REST API в моем канале, где я рассказываю про него и показываю, как использовать на практике.
-------------------------------------
Спорные вопросы:
Можно ли использовать метод POST для получения данных?
Можно ли сделать в проекте все методы POST?
Можно ли в GET передавать тело запроса?
Как правильно именовать эндпоинты - ед. число или мн. число (/user или /users)?
Как правильно строить URL - нужно ли писать create/update в названии метода?
Какой код ответа на метод POST: 200 или 201?
Что вернуть в ответ, если получен пустой результат - пустой массив или 404?
-------------------------------------
REST API - что это и для чего?
REST API - это архитектурный стиль, который определяет, по каким правилам приложения должны обмениваться данными между собой. Он используется для создания веб-сервисов, мобильных приложений, интеграционных платформ и других IT-решений.
Впервые был определен и описан Роем Филдингом в диссертации 2000-го года. Рой Филдинг - соавтор спецификаций HTTP и URI.
Главная цель REST API - облегчить передачу и управление информацией между разными системами: создавать, читать, изменять, удалять (CRUD). REST API использует для этого стандартные HTTP-запросы: GET, POST, PUT, DELETE и другие.
