5 ОШИБОК ПРОЕКТИРОВАНИЯ REST API

В этом видео о том, как правильно проектировать REST API и как избежать распространенные ошибки, а также как правильно использовать возможности протокола http в своем API.

[semenpetrov]

5 ошибок проектирования REST API

1) Включение тривиальных действий над ресурсами в URI самого ресурса (URI - универсальный идентификатор ресурса)
Пример неправильного использования: GET /GetPolis, POST /PostAgreement, PATCH /PatchAgreement, DELETE /DeleteSubject
2) Неправильное использование методов PATCH (частичная модификация объекта) и PUT (полная замена объекта)
3) Игнорирование возможности одновременной модификации одного и того же объекта разными клиентами (решение - включение тега версионности объекта или использовать заголовки if-mach и ETag или entity-tag)
4) Игнорирование TimeZone для тегов Дата и Время (использовать локальную дату + таймзона "Europe/Berlin" (UTC time и не UTC ofset - Universal Coordinated Time))
5) Игнорирование подробных кодов ответов, например возвращать 204 вместо 200, 401 403 409

Защита Backend'a от клиентов API
1) Постраничность - возвращаем порционно 1 страницу, используя токен последнего индекса записи, который передается в последующем запросе (лишняя неоправданная нагрузка)
2) Throtling лимиты на backend'e для приложений и для пользователей, если превышают то в ответе 429 Too many requests
3) API синхронизация между несколькими приложениями пользователей.

[nnzk]

отличное видео. все просто и понятно. очень рад что нашел ваш канал

[VanyaQA]

Спасибо большое за видео! Мне как тестировщику очень полезны эти видео

[transmorani]

спасибо. хотелось бы еще немного по этой теме

[yandoru]

Конкретно и по делу, класс, спасибо! 👍

[DZh]

Начал изучать C# после вашего видео про бэкенд, а теперь смотрю видосы про API и наткнулся на это ваше видео) Прям тепло на душе ) Спасибо за замечательный материал)

[fcnuehe]

Спасибо, очень многое для себя приметил

[AlexandrSpirit]

Спасибо
Стал изучать бекенд (написал приложение на фласке, переписал на фласке под API, теперь на FastAPI)
попутно изучаю фронт на VUE
Получается, сам под себя API пишу.
Приложение - небольшой ERP для отдела. Что-то вроде склада и движения материалов/продукта.

Хорошо бы услышать про этапы разработки API с примером под е-магазин. Без привязки к конкретному языку и фреймворку... Главное - правильный подход.
У меня например возникают сомнения - в каком объеме серверу отдавать данные. Например на фронте таблица с 3 полями. Но если мы должны редактировать строку, то должны видеть все поля записи... а их не 3 а 30.
Можно сразу большой JSON передать со всеми полями, но выводить сначала по 3 поля для строки, а можно только по 3 поля для каждой строки, а если редактировать нужно - запросить полные данные. И что из этого лучше?
Как правильно пагинацию реализовать?
Как реализовывается поиск?

[trubntr]

Спасибо за видео, познавательно. На текущий момент времени погружаюсь в системную аналитику, могла бы посоветовать тематические ресурсы или книги по проектированию API? Спасибо!

[semenpetrov]

Были такие ошибки в моем опыте при проектировании API: 1) Метод расчета итоговой суммы работал в фоновом режиме, он возвращал пустоту т.е. просто код 200 вместо результатов расчета, клиенты не понимали что делать, вроде метод отработал успешно, но результата в ответе нет - чтобы получить результат расчета нужно было выполнить другой метод. 2) Создавать API, который позволяет клиентам писать информацию напрямую в БД (клиенты часто спамят, тукают наугад методы, не понимая логику работу API, это "замусоривает" БД). В качестве решения используются некие адаптеры, которые пропускают через себя входящий трафик от клиентов и могут ограничивать кол-во запросов (от ддос атак например) и проверять первичные входные данные клиентов хотя бы на адекватность. 3) Набрасывать на один ресурс (метод) несколько функционалов, например, вызываешь метод создания меню, указываешь все параметры, но есть некий параметр-тригер, значение которого критично, т.е. если передать в нём положительное число, будет создано новое меню, если передать в нем значение 0, то ничего не произойдёт и если передать в нем отрицательное число то будет произведен автоматический поиск существующего в базе меню, похожего на текущее и выдано как результата. А если таких параметров несколько - Клиенты просто путаются в сложной логике работы сервиса. если еще что вспомню, допишу

[KlGleb]

8:20 -- а разве я не могу время в формате UTC перевести и сконвертировать в какой угодно формат и таймзону?

[jenpsaki]

Спасибо за информацию. Все понятно изложено. Очень красивая девушка)

[pavel_dev]

Умничка. Нравится твой скрипучий голос.Если бы еще и улыбалась-была бы супер девочка

[anton-tkachenko]

Особо кекнул с хумуса, чикпиз и тхины :)

[ID-suwj]

Подскажите, не могу у Firestore получить валидный resource.auth. Использую Rest Api. После успешных SignUp и SignIn, делаю запрос, но этот объект не создан. Вопрос, Rest Api подразумевает хранение состояния на сервере? Т.е. мне искать ошибку в авторизаии либо в запросе (возможно не добавил туда данные для auth)?

[eugenechernyshenko]

Тема про время на сервере и в api не раскрыта. Как вы храните время в базе? UTC или нет. Где вы его приводите ко времени клиента, на клиенте или на бэке?

[semenpetrov]

Вопрос: Если я предоставляю API для клиента, должен ли я предоставить все необходимые справочники для этого, даже если эти справочники есть в общем доступе, например, список банков РФ, справочники адресов КЛАДР, ФИАС и т.д.?

[zhbxkjm]

Ох, к сожалению все API с которыми доводилось интегрироваться, да, и чего греха таить, писать были далеки от REST. Начиная от GET/POST которые у нас обычно единственные HTTP глаголы и заканчивая тем что 200 это ОК, а 400 это ошибка на сервере.

[yrrqwen]

Не понятно, почему нельзя использовать время UTC ?

[cloudfog]

А це обов'язково з такою пригніченою інфтонацією розказувати?