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
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 синхронизация между несколькими приложениями пользователей.
Начал изучать C# после вашего видео про бэкенд, а теперь смотрю видосы про API и наткнулся на это ваше видео) Прям тепло на душе ) Спасибо за замечательный материал)
Спасибо Стал изучать бекенд (написал приложение на фласке, переписал на фласке под API, теперь на FastAPI) попутно изучаю фронт на VUE Получается, сам под себя API пишу. Приложение - небольшой ERP для отдела. Что-то вроде склада и движения материалов/продукта. Хорошо бы услышать про этапы разработки API с примером под е-магазин. Без привязки к конкретному языку и фреймворку... Главное - правильный подход. У меня например возникают сомнения - в каком объеме серверу отдавать данные. Например на фронте таблица с 3 полями. Но если мы должны редактировать строку, то должны видеть все поля записи... а их не 3 а 30. Можно сразу большой JSON передать со всеми полями, но выводить сначала по 3 поля для строки, а можно только по 3 поля для каждой строки, а если редактировать нужно - запросить полные данные. И что из этого лучше? Как правильно пагинацию реализовать? Как реализовывается поиск?
Спасибо за видео, познавательно. На текущий момент времени погружаюсь в системную аналитику, могла бы посоветовать тематические ресурсы или книги по проектированию API? Спасибо!
Были такие ошибки в моем опыте при проектировании API: 1) Метод расчета итоговой суммы работал в фоновом режиме, он возвращал пустоту т.е. просто код 200 вместо результатов расчета, клиенты не понимали что делать, вроде метод отработал успешно, но результата в ответе нет - чтобы получить результат расчета нужно было выполнить другой метод. 2) Создавать API, который позволяет клиентам писать информацию напрямую в БД (клиенты часто спамят, тукают наугад методы, не понимая логику работу API, это "замусоривает" БД). В качестве решения используются некие адаптеры, которые пропускают через себя входящий трафик от клиентов и могут ограничивать кол-во запросов (от ддос атак например) и проверять первичные входные данные клиентов хотя бы на адекватность. 3) Набрасывать на один ресурс (метод) несколько функционалов, например, вызываешь метод создания меню, указываешь все параметры, но есть некий параметр-тригер, значение которого критично, т.е. если передать в нём положительное число, будет создано новое меню, если передать в нем значение 0, то ничего не произойдёт и если передать в нем отрицательное число то будет произведен автоматический поиск существующего в базе меню, похожего на текущее и выдано как результата. А если таких параметров несколько - Клиенты просто путаются в сложной логике работы сервиса. если еще что вспомню, допишу
Тема про время на сервере и в api не раскрыта. Как вы храните время в базе? UTC или нет. Где вы его приводите ко времени клиента, на клиенте или на бэке?
Вопрос: Если я предоставляю API для клиента, должен ли я предоставить все необходимые справочники для этого, даже если эти справочники есть в общем доступе, например, список банков РФ, справочники адресов КЛАДР, ФИАС и т.д.?
Подскажите, не могу у Firestore получить валидный resource.auth. Использую Rest Api. После успешных SignUp и SignIn, делаю запрос, но этот объект не создан. Вопрос, Rest Api подразумевает хранение состояния на сервере? Т.е. мне искать ошибку в авторизаии либо в запросе (возможно не добавил туда данные для auth)?
Вся эта теория конечно хорошо, но на практике намного больше бесят другие вещи: 1. Отсутствие валидации и понятной ошибки. Т.е. передал запрос с 50 полями, получил в ответ 500 ответ без текста ошибки. И сиди гадай, в каком поле ты указал невалидные данные. 2. Это апи, разработчики которого не пишут авто-тесты, и в их апи постоянно что-то ломается. А самое главное - приходится сильно усложнять свою программу, чтобы она эти бесконечные ошибки могла "пережевывать" (например, добавлять функционал, когда любой запрос может отправляться несколько раз, до тех пор, пока не будет получен нормальный ответ).
Ох, к сожалению все API с которыми доводилось интегрироваться, да, и чего греха таить, писать были далеки от REST. Начиная от GET/POST которые у нас обычно единственные HTTP глаголы и заканчивая тем что 200 это ОК, а 400 это ошибка на сервере.
@@GC_WK2 банальная работа с заказом (двумя и более менеджерами). Заказ не могут обрабатывать 2 человека. Когда один заходит и редачит, заказ блокируется и его нельзя менять от лица 2, 3 и т.д. менеджера. А теперь представь версионирование в заказе, это ебаный ад для менеджера. Тоже самое можно отнести к блогам, интернет магазинам, инфопорталам. Я работаю с этим и знаю о чем говорю. Пока на практике версионирование нигде не пригодилось
3 пункт не корректен для RESTful API. Это не обязанность бэкенда поддерживать актуальное состояние. Клиент сам решает когда у него есть проблема с concurrency. RESTful API должен быть stateless.
Ну типо разобрать принципы REST которые могут нарушаться, а главное как нарушаться при разработке апи, прям с примерами - было бы профитнее для народа. А у тебя прям уже нишевая тема так скзть.
отличное видео. все просто и понятно. очень рад что нашел ваш канал
спасибо :)
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 :)
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 синхронизация между несколькими приложениями пользователей.
Спасибо!
Начал изучать C# после вашего видео про бэкенд, а теперь смотрю видосы про API и наткнулся на это ваше видео) Прям тепло на душе ) Спасибо за замечательный материал)
аналогичная ситуация)
Очень толково, спасибо!
Крутое видео. Опять важная тема.
Спасибо
Стал изучать бекенд (написал приложение на фласке, переписал на фласке под API, теперь на FastAPI)
попутно изучаю фронт на VUE
Получается, сам под себя API пишу.
Приложение - небольшой ERP для отдела. Что-то вроде склада и движения материалов/продукта.
Хорошо бы услышать про этапы разработки API с примером под е-магазин. Без привязки к конкретному языку и фреймворку... Главное - правильный подход.
У меня например возникают сомнения - в каком объеме серверу отдавать данные. Например на фронте таблица с 3 полями. Но если мы должны редактировать строку, то должны видеть все поля записи... а их не 3 а 30.
Можно сразу большой JSON передать со всеми полями, но выводить сначала по 3 поля для строки, а можно только по 3 поля для каждой строки, а если редактировать нужно - запросить полные данные. И что из этого лучше?
Как правильно пагинацию реализовать?
Как реализовывается поиск?
Чудове відео! Дякую!
Спасибо за видео, познавательно. На текущий момент времени погружаюсь в системную аналитику, могла бы посоветовать тематические ресурсы или книги по проектированию API? Спасибо!
8:20 -- а разве я не могу время в формате UTC перевести и сконвертировать в какой угодно формат и таймзону?
спасибо. хотелось бы еще немного по этой теме
Были такие ошибки в моем опыте при проектировании API: 1) Метод расчета итоговой суммы работал в фоновом режиме, он возвращал пустоту т.е. просто код 200 вместо результатов расчета, клиенты не понимали что делать, вроде метод отработал успешно, но результата в ответе нет - чтобы получить результат расчета нужно было выполнить другой метод. 2) Создавать API, который позволяет клиентам писать информацию напрямую в БД (клиенты часто спамят, тукают наугад методы, не понимая логику работу API, это "замусоривает" БД). В качестве решения используются некие адаптеры, которые пропускают через себя входящий трафик от клиентов и могут ограничивать кол-во запросов (от ддос атак например) и проверять первичные входные данные клиентов хотя бы на адекватность. 3) Набрасывать на один ресурс (метод) несколько функционалов, например, вызываешь метод создания меню, указываешь все параметры, но есть некий параметр-тригер, значение которого критично, т.е. если передать в нём положительное число, будет создано новое меню, если передать в нем значение 0, то ничего не произойдёт и если передать в нем отрицательное число то будет произведен автоматический поиск существующего в базе меню, похожего на текущее и выдано как результата. А если таких параметров несколько - Клиенты просто путаются в сложной логике работы сервиса. если еще что вспомню, допишу
Ну первый пункт не ошибка. Если расчет занимает много времени, то вполне нормально так делать.
Спасибо большое за видео! Мне как тестировщику очень полезны эти видео
Ну блин круто рассказала :=)
Спасибо за информацию. Все понятно изложено. Очень красивая девушка)
Конкретно и по делу, класс, спасибо! 👍
Спасибо, очень многое для себя приметил
Отличное видео!
Огонь, спасибо
Спасибо! Лайк и подписка!
круто ,очень круто.
Тема про время на сервере и в api не раскрыта. Как вы храните время в базе? UTC или нет. Где вы его приводите ко времени клиента, на клиенте или на бэке?
Умничка. Нравится твой скрипучий голос.Если бы еще и улыбалась-была бы супер девочка
ты такая няша.........
А це обов'язково з такою пригніченою інфтонацією розказувати?
Не понятно, почему нельзя использовать время UTC ?
Да, и на клиенте приводить к нужному.
Может я чего-то не знаю, но по-моему, это и есть самый адекватный способ.
Вопрос: Если я предоставляю API для клиента, должен ли я предоставить все необходимые справочники для этого, даже если эти справочники есть в общем доступе, например, список банков РФ, справочники адресов КЛАДР, ФИАС и т.д.?
Как по мне, будет достаточно вернуть в ответе (в месте с сущностью) ссылки на эти справочники (если они в открытом доступе).
Спасибо!
Особо кекнул с хумуса, чикпиз и тхины :)
Подскажите, не могу у Firestore получить валидный resource.auth. Использую Rest Api. После успешных SignUp и SignIn, делаю запрос, но этот объект не создан. Вопрос, Rest Api подразумевает хранение состояния на сервере? Т.е. мне искать ошибку в авторизаии либо в запросе (возможно не добавил туда данные для auth)?
круто
Вся эта теория конечно хорошо, но на практике намного больше бесят другие вещи:
1. Отсутствие валидации и понятной ошибки. Т.е. передал запрос с 50 полями, получил в ответ 500 ответ без текста ошибки. И сиди гадай, в каком поле ты указал невалидные данные.
2. Это апи, разработчики которого не пишут авто-тесты, и в их апи постоянно что-то ломается. А самое главное - приходится сильно усложнять свою программу, чтобы она эти бесконечные ошибки могла "пережевывать" (например, добавлять функционал, когда любой запрос может отправляться несколько раз, до тех пор, пока не будет получен нормальный ответ).
Ох, к сожалению все API с которыми доводилось интегрироваться, да, и чего греха таить, писать были далеки от REST. Начиная от GET/POST которые у нас обычно единственные HTTP глаголы и заканчивая тем что 200 это ОК, а 400 это ошибка на сервере.
Версионирование - спорный момент не везде ее можно использовать. Лучше делать временную блокировку.
Как блокировка решит проблему разных версий? Запрос лишь не выполнится пока не снимется блокировка, но перезапись данных это никак не отменит.
@@GC_WK2 банальная работа с заказом (двумя и более менеджерами). Заказ не могут обрабатывать 2 человека. Когда один заходит и редачит, заказ блокируется и его нельзя менять от лица 2, 3 и т.д. менеджера.
А теперь представь версионирование в заказе, это ебаный ад для менеджера. Тоже самое можно отнести к блогам, интернет магазинам, инфопорталам. Я работаю с этим и знаю о чем говорю.
Пока на практике версионирование нигде не пригодилось
Жаль у меня не было такого препода
3 пункт не корректен для RESTful API. Это не обязанность бэкенда поддерживать актуальное состояние. Клиент сам решает когда у него есть проблема с concurrency. RESTful API должен быть stateless.
За использование POST для изменения сущностей надо бить крышкой от рояля по пальцам
Ну типо разобрать принципы REST которые могут нарушаться, а главное как нарушаться при разработке апи, прям с примерами - было бы профитнее для народа. А у тебя прям уже нишевая тема так скзть.
Выспаться сначала надо,а потом в люди ити
Норм тёлочка . А о чем она тут рассказывает ?
Выпусти, так сказать, пар и пересмотри еще раз. Отпустят туманящие разум мысли, станет легче воспринимать инфу, может поймешь
ужасный голос. но видео норм
время в коде лучше использовать в мс, а уже для визуализации пользователю накидать нормальный формат с учётом тз браузера
Очень полезное видео! 😊