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

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 синхронизация между несколькими приложениями пользователей.

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

Жаль у меня не было такого препода

Ну типо разобрать принципы REST которые могут нарушаться, а главное как нарушаться при разработке апи, прям с примерами - было бы профитнее для народа. А у тебя прям уже нишевая тема так скзть.

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

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

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

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

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

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

Ну блин круто рассказала :=)

Вся эта теория конечно хорошо, но на практике намного больше бесят другие вещи: 1. Отсутствие валидации и понятной ошибки. Т.е. передал запрос с 50 полями, получил в ответ 500 ответ без текста ошибки. И сиди гадай, в каком поле ты указал невалидные данные. 2. Это апи, разработчики которого не пишут авто-тесты, и в их апи постоянно что-то ломается. А самое главное - приходится сильно усложнять свою программу, чтобы она эти бесконечные ошибки могла "пережевывать" (например, добавлять функционал, когда любой запрос может отправляться несколько раз, до тех пор, пока не будет получен нормальный ответ).

Крутое видео. Опять важная тема.

3 пункт не корректен для RESTful API. Это не обязанность бэкенда поддерживать актуальное состояние. Клиент сам решает когда у него есть проблема с concurrency. RESTful API должен быть stateless.

Выспаться сначала надо,а потом в люди ити

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

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

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

Очень толково, спасибо!

За использование POST для изменения сущностей надо бить крышкой от рояля по пальцам

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

Чудове відео! Дякую!

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

ты такая няша.........

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

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

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

Отличное видео!

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

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

Огонь, спасибо

Очень полезное видео! 😊

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

Версионирование - спорный момент не везде ее можно использовать. Лучше делать временную блокировку.

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

Спасибо! Лайк и подписка!

круто ,очень круто.

круто

Спасибо!

Норм тёлочка . А о чем она тут рассказывает ?

ужасный голос. но видео норм