Комментарии 8
Делайте хорошо, а плохо - не делайте. Как это всё сочетается с началом статьи, где про жёсткие дедлайны и давление бизнеса? Вот про проектирование в таких и ещё и постоянно меняющихся условиях я бы почитал.
Ну а как же:
Проектирование публичного API, когда заранее неизвестны способы использования (ваши догадки всегда неверны)
Авторизация и аутентификация. Права, роли.
Если права пользователя не дают доступ к каким-то полям ответа - отдельный эндпоинт для каждой роли с соответствующей документацией и схемой или поля опциональные (валидация схемы коту под хвост) или nullable и как это все описать в доках?
REST, RESTful, RPC и различное понимание этих слов разными разработчиками.
Кеширование, мультизональность, заголовки, безопасность.
Что делать с GET если параметры не влезают в query string
На каком языке возвращать текст «поле email заполнено неверно»? И нужно ли заводить машиночитаемые коды ошибок для каждого поля?
И конечно же холивар: «товар» не найден - это 404 или 200 с ошибкой?
Удачного проектирования API ;)
На каком языке
Лично я обычно делаю (в своих библиотеках, например) параметр lang или аналогичный и вывожу сообщения из соответствующего файла.
Если ничего не задано, то из файла err_msg_ru.txt или err_msg_en.txt, в зависимости от умолчаний проекта. А, так-то любой может записать файл err_msg_sw.txt, установить lang = sw, чтобы мой же код отвечал ему на суахили.
И нужно ли заводить машиночитаемые коды ошибок
Лучше завести. )) При стандартном подходе, когда есть отдельное описание на систему ошибок кода, это недолго.
8. И конечно же холивар: «товар» не найден - это 404 или 200 с ошибкой?
Зачем холиварить? Если REST — 404. Если RPC-like — 200 с кодом и пояснением ошибки в теле.
Первая иллюстрация в статье после списка ошибок 4xx поразила до глубины души!!!
Так держать! Нам — людям — не хватает качественных материалов в это жуткое время взрывного роста нейросетевого пустословия!

Как спроектировать API, которое не придется переписывать через полгода