5 ОШИБОК ПРОЕКТИРОВАНИЯ REST API
Vložit
- čas přidán 1. 02. 2020
- В этом видео о том, как правильно проектировать REST API и как избежать распространенные ошибки, а также как правильно использовать возможности протокола http в своем API.
Почему нужно сохранять таймзону - almaleksia.github.io/2019/06/...
Спецификация HTTP - tools.ietf.org/html/rfc2616
Условные запросы (If-Match, ETag) - tools.ietf.org/html/rfc7232
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 синхронизация между несколькими приложениями пользователей.
Спасибо!
Очень толково, спасибо!
отличное видео. все просто и понятно. очень рад что нашел ваш канал
спасибо :)
I dont mean to be so offtopic but does anyone know of a way to get back into an instagram account??
I was stupid lost the account password. I love any tips you can give me
@Jeremiah Jase Instablaster :)
Крутое видео. Опять важная тема.
Конкретно и по делу, класс, спасибо! 👍
Спасибо большое за видео! Мне как тестировщику очень полезны эти видео
Отличное видео!
Чудове відео! Дякую!
Ну блин круто рассказала :=)
Очень полезное видео! 😊
спасибо. хотелось бы еще немного по этой теме
Начал изучать C# после вашего видео про бэкенд, а теперь смотрю видосы про API и наткнулся на это ваше видео) Прям тепло на душе ) Спасибо за замечательный материал)
аналогичная ситуация)
Спасибо, очень многое для себя приметил
Огонь, спасибо
Спасибо за видео, познавательно. На текущий момент времени погружаюсь в системную аналитику, могла бы посоветовать тематические ресурсы или книги по проектированию API? Спасибо!
круто ,очень круто.
Спасибо! Лайк и подписка!
8:20 -- а разве я не могу время в формате UTC перевести и сконвертировать в какой угодно формат и таймзону?
Спасибо
Стал изучать бекенд (написал приложение на фласке, переписал на фласке под API, теперь на FastAPI)
попутно изучаю фронт на VUE
Получается, сам под себя API пишу.
Приложение - небольшой ERP для отдела. Что-то вроде склада и движения материалов/продукта.
Хорошо бы услышать про этапы разработки API с примером под е-магазин. Без привязки к конкретному языку и фреймворку... Главное - правильный подход.
У меня например возникают сомнения - в каком объеме серверу отдавать данные. Например на фронте таблица с 3 полями. Но если мы должны редактировать строку, то должны видеть все поля записи... а их не 3 а 30.
Можно сразу большой JSON передать со всеми полями, но выводить сначала по 3 поля для строки, а можно только по 3 поля для каждой строки, а если редактировать нужно - запросить полные данные. И что из этого лучше?
Как правильно пагинацию реализовать?
Как реализовывается поиск?
Спасибо за информацию. Все понятно изложено. Очень красивая девушка)
Спасибо!
Были такие ошибки в моем опыте при проектировании API: 1) Метод расчета итоговой суммы работал в фоновом режиме, он возвращал пустоту т.е. просто код 200 вместо результатов расчета, клиенты не понимали что делать, вроде метод отработал успешно, но результата в ответе нет - чтобы получить результат расчета нужно было выполнить другой метод. 2) Создавать API, который позволяет клиентам писать информацию напрямую в БД (клиенты часто спамят, тукают наугад методы, не понимая логику работу API, это "замусоривает" БД). В качестве решения используются некие адаптеры, которые пропускают через себя входящий трафик от клиентов и могут ограничивать кол-во запросов (от ддос атак например) и проверять первичные входные данные клиентов хотя бы на адекватность. 3) Набрасывать на один ресурс (метод) несколько функционалов, например, вызываешь метод создания меню, указываешь все параметры, но есть некий параметр-тригер, значение которого критично, т.е. если передать в нём положительное число, будет создано новое меню, если передать в нем значение 0, то ничего не произойдёт и если передать в нем отрицательное число то будет произведен автоматический поиск существующего в базе меню, похожего на текущее и выдано как результата. А если таких параметров несколько - Клиенты просто путаются в сложной логике работы сервиса. если еще что вспомню, допишу
Ну первый пункт не ошибка. Если расчет занимает много времени, то вполне нормально так делать.
круто
ты такая няша.........
Подскажите, не могу у Firestore получить валидный resource.auth. Использую Rest Api. После успешных SignUp и SignIn, делаю запрос, но этот объект не создан. Вопрос, Rest Api подразумевает хранение состояния на сервере? Т.е. мне искать ошибку в авторизаии либо в запросе (возможно не добавил туда данные для auth)?
Вопрос: Если я предоставляю API для клиента, должен ли я предоставить все необходимые справочники для этого, даже если эти справочники есть в общем доступе, например, список банков РФ, справочники адресов КЛАДР, ФИАС и т.д.?
Как по мне, будет достаточно вернуть в ответе (в месте с сущностью) ссылки на эти справочники (если они в открытом доступе).
Тема про время на сервере и в api не раскрыта. Как вы храните время в базе? UTC или нет. Где вы его приводите ко времени клиента, на клиенте или на бэке?
Особо кекнул с хумуса, чикпиз и тхины :)
Умничка. Нравится твой скрипучий голос.Если бы еще и улыбалась-была бы супер девочка
Жаль у меня не было такого препода
Ох, к сожалению все API с которыми доводилось интегрироваться, да, и чего греха таить, писать были далеки от REST. Начиная от GET/POST которые у нас обычно единственные HTTP глаголы и заканчивая тем что 200 это ОК, а 400 это ошибка на сервере.
Не понятно, почему нельзя использовать время UTC ?
Да, и на клиенте приводить к нужному.
Может я чего-то не знаю, но по-моему, это и есть самый адекватный способ.
За использование POST для изменения сущностей надо бить крышкой от рояля по пальцам
А це обов'язково з такою пригніченою інфтонацією розказувати?
Версионирование - спорный момент не везде ее можно использовать. Лучше делать временную блокировку.
Как блокировка решит проблему разных версий? Запрос лишь не выполнится пока не снимется блокировка, но перезапись данных это никак не отменит.
@@GC_WK2 банальная работа с заказом (двумя и более менеджерами). Заказ не могут обрабатывать 2 человека. Когда один заходит и редачит, заказ блокируется и его нельзя менять от лица 2, 3 и т.д. менеджера.
А теперь представь версионирование в заказе, это ебаный ад для менеджера. Тоже самое можно отнести к блогам, интернет магазинам, инфопорталам. Я работаю с этим и знаю о чем говорю.
Пока на практике версионирование нигде не пригодилось
Вся эта теория конечно хорошо, но на практике намного больше бесят другие вещи:
1. Отсутствие валидации и понятной ошибки. Т.е. передал запрос с 50 полями, получил в ответ 500 ответ без текста ошибки. И сиди гадай, в каком поле ты указал невалидные данные.
2. Это апи, разработчики которого не пишут авто-тесты, и в их апи постоянно что-то ломается. А самое главное - приходится сильно усложнять свою программу, чтобы она эти бесконечные ошибки могла "пережевывать" (например, добавлять функционал, когда любой запрос может отправляться несколько раз, до тех пор, пока не будет получен нормальный ответ).
3 пункт не корректен для RESTful API. Это не обязанность бэкенда поддерживать актуальное состояние. Клиент сам решает когда у него есть проблема с concurrency. RESTful API должен быть stateless.
Ну типо разобрать принципы REST которые могут нарушаться, а главное как нарушаться при разработке апи, прям с примерами - было бы профитнее для народа. А у тебя прям уже нишевая тема так скзть.
Норм тёлочка . А о чем она тут рассказывает ?
Выпусти, так сказать, пар и пересмотри еще раз. Отпустят туманящие разум мысли, станет легче воспринимать инфу, может поймешь
ужасный голос. но видео норм