Просто один из примеров того, как надо записывать обзорные видео. Кратко, схематично, очень последовательно. Просто снимаю шляпу, автору лайк, подписка и в сохраненные. Как аниматор со стажем, хочу отметить ещё и анимационный подход. Всё минималистично, плавно и к месту.
Очень качественный материал, спасибо за потраченное на создание время! Я по профессии QA, мне оказалось полезным, то что надо, чтобы разложить разрозненные знания по полочкам и вспомнить то, что знаю, но забыл!
Отличное видео, спасибо за работу. Вроде большинство из этого уже известно, но из-за того что опыта пока мало все в голове тяжело удержать, надо периодически повторять :)
Очень хорошо объяснил, для новичков я бы ещё добавил картинки запросов, ответов с заголовками, чтобы было понятно где находится код, используемый метод и т.д. Curl их обычно в консоль выкидывает по запросу.
Я использовал users - выдача всех пользователей, а user/{id} отдача конкретного. И посчитал что так интуитивнее понятнее) Но сейчас понимаю, что по сути и верно было множественное и из него выборка уже... Но уже 3 версии продукта прошло и менять этого конечно никто не будет
на 1:10 приведена некорректная таблица. Единственное что в ней является архитектурным стилем - это REST. В целом, если эта информация от начинающего разработчика без какого либо бэкграунда - то в целом, ок. Но надо иметь в виду что приведет людей к заблуждению в терминологии, как минимум.
Спасибо. Добавьте пункт об описании интерфейса API. По запросу, например get=options пользователь должен получить инструкции (help) о ключах и методах.
По хорошему, у каждого приложения должен быть GET /entrypoint - входная точка, которая выдает массив объектов «гиперссылок» с полями title, method, href, rel добавить можно хоть что но есть стандарты у каждой компании. В этом массиве всегда есть ссылки и описание чтоб клиенты (к примеру reactjs) могли парсить их для того что бы понять куда отправлять запрос дальше, как только ссылка отпределена и запрос сделан, далее в ответе вместе с данными, должен быть снова массив links где так же ссылки на то что дальше можно сделать, и так может быть бесконечно, то есть API дает знать клиентам о том как оно работает.
Видео понравилось, подача отличная, спасибо за Ваш труд. Считаю бы лучше если помимо самих советов указывать еще и статьи/литературу на чем они основываются. Так помимо информации даваемой Вами можно будет еще и получить углубленное понимание 😀
Отдельно напишу коммент по содержанию. Все обстоятельно. Мне не хватило, пожалуй, про передачу данных. В каком случае это делать в заголовках, в каком - в теле запроса, в каком - через адресную строку. Я знаю мало, и мне бывает интересно, почему одни полагаются на заголовки, а другие на body. И например, гет- запросы не должны передавать данные в теле, хотя такое технически возможно.
У Get нет body, соответственно в URL передавать параметры запроса. В заголовках передается или JWT токен аутентификации или куки. POST, PUT,PATCH - передаём в Body. Delete тут не уверен, иногда достаточно URL, иногда нужно в теле указать что удалять.
Иногда для получения информации вы должны передать очень много информации и тогда GET не очень хорошая идея, лучше заюзать POST и в теле перечислить ваш бесконечный список условий, например. Однако это обязательно должно быть нормально документировано
Как-то сумбурно В начале написано restful, а описывается rest api, игнорируя последние три буквы . При этом первым пунктом в бестпрактис - это используйте GET/POST/PUT/DELETE - а это собственно есть последние три буквы. Т.е. REST - это формат обмена, т.е. json поверх HTTP, а RESTful - это уже способ проектирования апи, на основе REST. Кэширование - не являются частью API, как и Rate Limiter, тоже не являются, но раз уж о них, то где circuit breaker? Про пароли в теле запроса, дело ни в том, что в теле запроса оно лежит безопасней, тело запроса точно также логируется на проксисервере, там в целом весь запрос логируется, дело в том, что во первых метод логина - не иденпотентен и не может быть GET по условиям RESTful, а во вторых - дело в том, что методы GET и POST обычно имеют разную политику обработки на уровне маршрутизации и безопасности (даже на уровне CORS это сделано). Если авторизация сделана через GET, логин и пароль можно увести через простую ссылку, хоть на картинку в обычном html
Вместе с 429 принято возвращать заголовок Retry-After, который идет по стандарту. Так многие клиенты смогут автоматически подождать и не перенастраивать на ваши кастомные заголовки
Глаголы это, конечно, хорошо, но в крупных проектах лучше всего подходит json Api, пост на всё и 200 на всё, а ошибки в теле ответа. Да и вообще grpc намного удобнее, особенно если сервисов дохрена. Работаю в бигтехе, знаю о чем говорю.
@Pokaznoy тем, что не смешиваются транспорт и логика. С 404 не понять - нет запрошенной сущности (логика приложения) или нет такой страницы (проблемы транспорта).
По поводу ошибок на 4 минуте - вообще не согласен. Если у тебя очень много ошибок, для которых не всегда подходит тот или иной код http, то лучше и проще всегда отдавать 200 код, который символизирует, что запрос был обраюотан, если нет -500, а далее уже смотрим в тело ответа и отдаём клиенту. Пример такой реализации использует Cloudflare и др компании
Дизайн api совет 4. Ремарка, понятное описание должно быть на всем кроме авторизации. Не нужно говорить пользователю что он ввел пароль не верно. Лучше писать, что логин или пароль были введены неправильно, так вы повысите безопасность системы
Недавно разрабатывал свое первое REST API приложение, сейчас наткнулся на ваше видео и понял что уже с нуля разрабатывал его по лучшим практикам, но из видео стало ясно чего не хватало. На каком языке вы разрабатываете?
Про коды - откровенная лажа. Эти коды относятся к веб-серверу. Если код дошел до обработчика - никакого ответа кроме 200 быть не должно. Почему? Потому что опять - а как твой клиент поймет, это 404 из-за того что nginx на балансировщике отдал, или юзера нет в БД? А никак, он все равно должен будет полезть в тело. А если он и так лезет в тело - на кой фиг ты отдаешь код который относится фиг пойми к чему? Вот зачем? Вот что ты этим хочешь достичь? Далее, вся эта фигня с "рестфул" ведет к тому, что у тебя по сути каждый эндпоинт может разный формат сообщения отдать, ведь с точки зрения рест - это разные ресурсы. Офигенно же. В результате - у тебя юзеры отдаются так, товары эдак, а теги вот так вот. Это конечно в крайнем случае, но не суть. А суть в том, что не натягивайте HTTP на приложение. Оно не для этого придумано, протокол HTTP придуман для веб-сервера непосредственно, ваше приложение - оно уже за веб-сервером. У него должны быть свои коды. И если до вас дошел запрос - альтернативы кроме как отдать 200 быть не должно. Потому что - ну, а чего бы тогда коды TCP для информирования об ошибках не использовать? Шли RST и кайфуй) Плюс - дальше - ваше приложение надо будет выносить за HTTP, на какой-нибудь jsonRPC или еще что-то. Че делать будем? Переделывать половину инфраструктурной части, чтобы тот же, в рамках приложения, но отличающийся транспортом запрос? Ну не бред ли? Короче. Пилишь веб-сервер - используешь коды HTTP для ответа. Если пилишь приложение - всегда возвращаешь 200 и не насилуешь мозги ни себе ни людям.
11:05 Как парсить потом форматы дат? У нас на входе строка с содержимым 2023-03-15 (...Хоть что...) Не проще передавать сразу ISO строку без дополнительных единиц измерения? (ну и конечно применить валидацию на ISO строку) Мы можем измерить массу в кг и фунтах, но дату передавать в любом виде, кроме как ISO строка - идея так себе, поэтому обозначение в скобках просто избыточно
Дизайн API: Совет 6 ( 14:57 ). С ним проблема. Со стороны клиента приложения - такой endpoint не особо полезен. Факт того что бакэнд приложение не работает, можно выяснить по любому запросу. Но это слабый аргумент. А вот сильный - что должно вернуться клиенту, если в момент запроса из 10 запущенных инстансов приложения бакэнда (за балансировщиком) 8 работает, 1 запускается, а 1 не работает? Где будет реализована логика проверки работает/не работает? В балансировщике? А как он поймёт, что от него программист приложения хочет? Вообще, health check лучше прятать от внешнего клиента и оставлять его доступным только(!) инфраструктурным клиентам, типа балансировщика.
@@DlinnyLag для получения статуса в целом по инфраструктуре используют Atlassian status или аналоги. А в целом, если у вас 10 инстансов и 2 не работают - это нормально, на то их и много. Для клиента это Healthy. В случае падения производительности из-за вывода инстансов можно сервису дать статус Degraded.
Открой спецификацию http codes там все подробно описано. 201 это когда что-то создано успешно, например в базе данных заведен новый профиль. В абстракции не важно какой метод, главное что-то создано, но обычно это POST
0:03 Тема про API (не Web API). 0:33 Говорит о Web API, тут же называя его API. 1:04 говорит о WEB API. 1:24 Далее задается вопросом зачем нужно проектировать API (видимо имел ввиду WEB API), но объясняет зачем нужны API в принципе, перечисляя максимально абстрактные цели, причем на максимально далеком от практики примере. 5:14 "клиента отправляют к поддержке". Тут понятие клиент из архитектуры перепутано с понятием клиент из договора. 7:05 Говорит: "использование множественных чисел", имея ввиду существительные во множественном числе. 18:45 "масштабировать производительность" - одно слово лишнее. Выглядит так, что все что нашел в интернете по ключевыми словами, то и написал, а то что это разные понятия с похожими ключевыми словами - это не так важно. Мешанина из понятий Web API и API, клиентское приложение и клиент в юридическом смысле. Говорит об API, хотя имеет ввиду WEB API и прыгает с одного на другое.
Хорошее видео, но пример с идемпотентностью неправильный. DELETE должен возвращать одинаковый РЕЗУЛЬТАТ, а не изменять состояние системы. По REST у системы вообще не должно быть состояний. 6:24 как раз ошибочно будет вернуть 404 Not Found, если первый раз вернули 200/204.
Спасибо за комментарий, я рад, что видео понравилось :) Не совсем согласен с вами, хотя возможно мне нужно было явно проговорить, что говоря об идемпотентности, я подразумеваю изменение состояния ресурсов. Тут важно различать термин "состояние" в разных контекстах: 1. В REST "stateless" отсылает к тому, что ответственность за хранение информации о текущей сессии и её состоянии между запросами несет не сервер, а клиент. Другими словами, 'отсутствие состояния' в контексте REST означает, что каждый запрос должен быть самодостаточным и не зависеть от предыдущих запросов. Но это не значит, что ресурсы REST API не могут иметь различных состояний: пользователь удалён, в бане, создан и т.п. Отсюда и следует возможность получать различные ответы в зависимости от различных состояний ресурсов API. Юзера удалили - теперь получили 404, так как состояние ресурса поменялось. Сервер при этом всё ещё не хранит никакого состояния между запросами, он всё ещё оперирует только ресурсами и ничего не знает о предыдущих запросах. Это и есть stateless из REST. 2. В контексте идемпотентности я как раз говорю о состоянии ресурсов, повторный запрос не должен их изменять. При этом свойство идемпотентности никак не регламентирует поведение сервера. То есть идемпотентное удаление может быть реализовано как с вариантом кода 200 в смысле "ресурс уже удалён", так и 404, т.к. ресурс уже удалён (к тому же, 200 не всегда возможен, ведь не всегда используется мягкое удаление).
Слабо, очень слабо. По сути контент ради контента, а тема не раскрыта вовсе. Сначала автор лил воду, рассказывая что такое RestAPI, потом прошелся по про всем очевидные вещи, известные всем, такие так http заголовки и нейминг и даже там тему не раскрыл. Во первых использовать get для модифицирующих операций нельзя в первую очередь из соображений безопасности, а не приверженности дизайну (я могу скинуть ссылку залогиненому пользователю и перейдя по ней он непроизвольно выполнит действие) С неймингом все сложнее когда у вас нетривиальный пример ( нука скажите как должен выглядеть метод запуска ракеты ) Ну и самое главное, о чем не было сказано ни слова: одного rest недостаточно для спецификации, поэтому поверх него есть какая-нибудь OData или кастомный протокол, который единообразно описывает как должны выглядеть query params для фильтрации, респонсы с пагинацией и метаинформацией
Подскажите, пожалуйста, а как тогда быть? Попросить использовать параметр from_id? Это сделает поиск в MySQL, к примеру, быстрее, т.к. будут искаться записи по первичному ключу?
Ну ты малоумный конечно... Коречно лучше вернуть юзеру всю бд на 2 гига за раз, чтоб он потом еще раз обновил страницу и еще раз выкачал 2 гига, вместо 5 кб за условные 10 элементов. Может юзеру всего 30 элементов над будет увидеть до нужного результата
Комментарий, видео кншн прям очень банальное, напихал те самые практики с водой, так еще и в рамках http, ну ладно, целевая аудитория вроде в восторге.
@@popuguytheparrot_ спасибо за коммент! Настроить - да, хотя сейчас есть куча готовых вариантов вроде HAProxy, где достаточно небольшого конфигурационного файла для начала балансировки. А липкие сессии не нужны, если вы придерживаетесь REST подхода, ведь он подразумевает, что сервер не хранит информацию о запросах между сессиями. Кстати, в телеге расписал некоторые распространенные алгоритмы балансировки, если вдруг интересно :)
Это оба способа используются. Но чтоб было более порядочно, лучше версию давать всему приложению и если выходит новая версия например с 1.1.1 на 2.0.0 это означает что приложение имеет необратимые изменения, то есть чтоб поддерживать старых клиентов, нужно чтоб обе версии работали и передавать например header с той версией которая нужна клиенту. Ну а старую версию deprecate с датой, чтоб клиенты успели мигрировать до того как старую версию можно shutdown.
Посмотрел 1-ю минуту видео и уже там введение людей в заблуждение: REST - это не только HTTP и даже не обязательно HTTP. Транспортом может быть что угодно. Если уж с первоисточниками не сложилось, то хотя бы 1-й абзац русской википедии стоило прочитать.
@xdFOrfq8VVH6j5kXAh использование json схемы, запросы не являются идемподентными. Естественно передача параметров в body так длинна через get не позволяет.
@xdFOrfq8VVH6j5kXAh Мне вообще get не получается применять, в редких простых случаях. И то забиваешь на них и тоже через post делаешь. Но за видео спасибо, вроде толково рассказал. Но вот как проблему с post решить пока не понял.
@@l33ncore История переписки с ии. Вообще по правильному думаю для нее нужно наверно что типа redis поднимать. Но я пока rest гружу и бл. я там не выходит. Ну и плюсом там приходится масса других параметров передавать. Get не удобен.
@@maslennikovvaleriy Когда ты получаешь одну сущность по ID, то это плохая идея делать путь во множественном числе, а у тебя наоборот. Да, для API это не критично на самом деле, потому как пользователи не видят URL, но для остального стоит всё же логичные URL.
Просто один из примеров того, как надо записывать обзорные видео. Кратко, схематично, очень последовательно. Просто снимаю шляпу, автору лайк, подписка и в сохраненные. Как аниматор со стажем, хочу отметить ещё и анимационный подход. Всё минималистично, плавно и к месту.
@@practical-skills-school больше спасибо!
Согласен, как шпаргалка для разработчика
Очень хорошее видео. Без воды и с приятным визуалом ❤
Буду использовать как "настольную книгу" и пересматривать каждый, раз когда буду начинать новый проект, спасибо!
Одно из тех немногих видео, которое я досмотрел до конца. Спасибо!
Спасибо! Я фронтенд-разработчик, мимо проходил) Видео понравилось, четко структурировано, понятно и с примерами.
Видео огонь! Грамотная подача, четкий визуал, все по сущетсву, спасибо!
Очень круто! Кликнул на видео с мыслью освежить знания и не пожалел, структурированно и по делу, подписался :)
Один из лучших видосов что я смотрел по теме, крайне приятно смотреть и крайне полезно, прям хочется сделать шпаргалку
@@extressar679 спасибо!
Пожалуйста делай по больше таких видео, не концентрируйся на C#)
Супер полезное видео. Буду теперь всех джунов сюда отсылать, чтобы не объяснять самому одно и тоже.
Очень полезное видео для меня. Слайды супер. Спасибо! 👍👍👍
Жду с нетерпением новых видео.
Очень круто, молодец. Спасибо большое
Если добавить таймкоды, чтобы можно было возвращаться к видео время от времени, то вообще огонь будет
Очень качественный материал, спасибо за потраченное на создание время! Я по профессии QA, мне оказалось полезным, то что надо, чтобы разложить разрозненные знания по полочкам и вспомнить то, что знаю, но забыл!
Ппц, чуть не начал писать а тут такое... "дизайн апи" , прям оч вовремя, спс огромное.
Это лучшее объяснение! Спасибо!
Спасибо, интересно, полезно, без воды! Лайк, подписка и колокольчик 💪
Отличное видео, спасибо за работу. Вроде большинство из этого уже известно, но из-за того что опыта пока мало все в голове тяжело удержать, надо периодически повторять :)
То самое видео, которое досмотрел до конца. Хорошо
Прекрасное видео! Спасибо большое, жду ещё подобные видео.
Большое вам спасибо за такое полезное видео! Очень понравилось 😊
Очень хорошо объяснил, для новичков я бы ещё добавил картинки запросов, ответов с заголовками, чтобы было понятно где находится код, используемый метод и т.д. Curl их обычно в консоль выкидывает по запросу.
Очень классный визуал. Не планировал просвещаться в этой теме, но визуал так зацепил, что не могу оторваться )
Спасибо! Как раз тестировал формат, рад фидбеку 🙂
Всё вроде очевидно, но приятно еще раз послушать
Спасибо за информативный и познавательный контент! Привет из солнечного Узбекистана🇺🇿
Привет! И вам спасибо :)
Аналогия с всратым рестораном это угар. Топ, видно, что постарался над видео!
Я использовал users - выдача всех пользователей, а user/{id} отдача конкретного. И посчитал что так интуитивнее понятнее) Но сейчас понимаю, что по сути и верно было множественное и из него выборка уже... Но уже 3 версии продукта прошло и менять этого конечно никто не будет
Спасибо, очень четко! Помог разобраться.
на 1:10 приведена некорректная таблица. Единственное что в ней является архитектурным стилем - это REST. В целом, если эта информация от начинающего разработчика без какого либо бэкграунда - то в целом, ок. Но надо иметь в виду что приведет людей к заблуждению в терминологии, как минимум.
Отличное видео! Очень полезно.
Спасибо, неплохо было проговорить все это в качестве напоминания
Ждем видос про виды кеширования и подходы!!!
Спасибо. Добавьте пункт об описании интерфейса API. По запросу, например get=options пользователь должен получить инструкции (help) о ключах и методах.
По хорошему, у каждого приложения должен быть GET /entrypoint - входная точка, которая выдает массив объектов «гиперссылок» с полями title, method, href, rel добавить можно хоть что но есть стандарты у каждой компании. В этом массиве всегда есть ссылки и описание чтоб клиенты (к примеру reactjs) могли парсить их для того что бы понять куда отправлять запрос дальше, как только ссылка отпределена и запрос сделан, далее в ответе вместе с данными, должен быть снова массив links где так же ссылки на то что дальше можно сделать, и так может быть бесконечно, то есть API дает знать клиентам о том как оно работает.
Удобно, скрншотами можно сохраннять советы
Видео понравилось, подача отличная, спасибо за Ваш труд. Считаю бы лучше если помимо самих советов указывать еще и статьи/литературу на чем они основываются. Так помимо информации даваемой Вами можно будет еще и получить углубленное понимание 😀
Если бы у всех туториалов была такая подача, у нас бы уже были летающие машины
Ахаха, спасибо!
Отличное видео! Поддерживаю!
Отличный видос!
Сделайте видео как и где правильно использовать exceptions
А еще лучше использовать кебаб кейс, вместо кемел или снейк кейса. Это банально красивее выглядит в пути эндпоинта
Пишу для продвижения канала автора, выпуск огонь, учитывая что основной стек в контентенте не интересен. Даешь больше тем по архитектуре, бд и т.д.
Молодец бро
Отдельно напишу коммент по содержанию. Все обстоятельно. Мне не хватило, пожалуй, про передачу данных. В каком случае это делать в заголовках, в каком - в теле запроса, в каком - через адресную строку. Я знаю мало, и мне бывает интересно, почему одни полагаются на заголовки, а другие на body. И например, гет- запросы не должны передавать данные в теле, хотя такое технически возможно.
У Get нет body, соответственно в URL передавать параметры запроса.
В заголовках передается или JWT токен аутентификации или куки.
POST, PUT,PATCH - передаём в Body.
Delete тут не уверен, иногда достаточно URL, иногда нужно в теле указать что удалять.
Иногда для получения информации вы должны передать очень много информации и тогда GET не очень хорошая идея, лучше заюзать POST и в теле перечислить ваш бесконечный список условий, например. Однако это обязательно должно быть нормально документировано
@romankuznetsov4601 спасибо
Спасибо за видео, очень полезно )
Как-то сумбурно
В начале написано restful, а описывается rest api, игнорируя последние три буквы . При этом первым пунктом в бестпрактис - это используйте GET/POST/PUT/DELETE - а это собственно есть последние три буквы. Т.е. REST - это формат обмена, т.е. json поверх HTTP, а RESTful - это уже способ проектирования апи, на основе REST.
Кэширование - не являются частью API, как и Rate Limiter, тоже не являются, но раз уж о них, то где circuit breaker?
Про пароли в теле запроса, дело ни в том, что в теле запроса оно лежит безопасней, тело запроса точно также логируется на проксисервере, там в целом весь запрос логируется, дело в том, что во первых метод логина - не иденпотентен и не может быть GET по условиям RESTful, а во вторых - дело в том, что методы GET и POST обычно имеют разную политику обработки на уровне маршрутизации и безопасности (даже на уровне CORS это сделано). Если авторизация сделана через GET, логин и пароль можно увести через простую ссылку, хоть на картинку в обычном html
Те же вопросы возникли, согласен. Накрученные комменты с благодарностями так же вводят в заблуждение, думаешь что норм материал.
17:30 - вот так делать не надо точно.
Атакующие зная значения rate limit подстроят их так , что их переатанет срезать.
Вместе с 429 принято возвращать заголовок Retry-After, который идет по стандарту. Так многие клиенты смогут автоматически подождать и не перенастраивать на ваши кастомные заголовки
Я хз кто ты, но ты хорош. Все что хотел сказать, но не мог сформулировать
Глаголы это, конечно, хорошо, но в крупных проектах лучше всего подходит json Api, пост на всё и 200 на всё, а ошибки в теле ответа. Да и вообще grpc намного удобнее, особенно если сервисов дохрена. Работаю в бигтехе, знаю о чем говорю.
В каком именно бигтехе так принято?
И чем 200 на все лучше понятной ошибки ?
@Pokaznoy тем, что не смешиваются транспорт и логика. С 404 не понять - нет запрошенной сущности (логика приложения) или нет такой страницы (проблемы транспорта).
По поводу ошибок на 4 минуте - вообще не согласен. Если у тебя очень много ошибок, для которых не всегда подходит тот или иной код http, то лучше и проще всегда отдавать 200 код, который символизирует, что запрос был обраюотан, если нет -500, а далее уже смотрим в тело ответа и отдаём клиенту.
Пример такой реализации использует Cloudflare и др компании
Почему Джарахов рассказывает про api?
Что не понятного в GET/ POST /delete/{id}?
Что прям limit и offset? Это sql понятия. Почему не page и size?
Стоило рассказать, где имеет смысл применять Rest, особенно соответствующий Restful
Дизайн api совет 4. Ремарка, понятное описание должно быть на всем кроме авторизации. Не нужно говорить пользователю что он ввел пароль не верно. Лучше писать, что логин или пароль были введены неправильно, так вы повысите безопасность системы
Согласен :)
Недавно разрабатывал свое первое REST API приложение, сейчас наткнулся на ваше видео и понял что уже с нуля разрабатывал его по лучшим практикам, но из видео стало ясно чего не хватало. На каком языке вы разрабатываете?
@@exoneges C# чаще всего, иногда JS, если надо быстро сделать что-то маленькое
Пожалуйста сделай видео про OAuth 2.0
Про коды - откровенная лажа.
Эти коды относятся к веб-серверу. Если код дошел до обработчика - никакого ответа кроме 200 быть не должно.
Почему? Потому что опять - а как твой клиент поймет, это 404 из-за того что nginx на балансировщике отдал, или юзера нет в БД? А никак, он все равно должен будет полезть в тело.
А если он и так лезет в тело - на кой фиг ты отдаешь код который относится фиг пойми к чему? Вот зачем? Вот что ты этим хочешь достичь?
Далее, вся эта фигня с "рестфул" ведет к тому, что у тебя по сути каждый эндпоинт может разный формат сообщения отдать, ведь с точки зрения рест - это разные ресурсы. Офигенно же. В результате - у тебя юзеры отдаются так, товары эдак, а теги вот так вот. Это конечно в крайнем случае, но не суть.
А суть в том, что не натягивайте HTTP на приложение. Оно не для этого придумано, протокол HTTP придуман для веб-сервера непосредственно, ваше приложение - оно уже за веб-сервером. У него должны быть свои коды. И если до вас дошел запрос - альтернативы кроме как отдать 200 быть не должно.
Потому что - ну, а чего бы тогда коды TCP для информирования об ошибках не использовать? Шли RST и кайфуй)
Плюс - дальше - ваше приложение надо будет выносить за HTTP, на какой-нибудь jsonRPC или еще что-то. Че делать будем? Переделывать половину инфраструктурной части, чтобы тот же, в рамках приложения, но отличающийся транспортом запрос? Ну не бред ли?
Короче. Пилишь веб-сервер - используешь коды HTTP для ответа. Если пилишь приложение - всегда возвращаешь 200 и не насилуешь мозги ни себе ни людям.
11:05
Как парсить потом форматы дат?
У нас на входе строка с содержимым 2023-03-15 (...Хоть что...)
Не проще передавать сразу ISO строку без дополнительных единиц измерения? (ну и конечно применить валидацию на ISO строку)
Мы можем измерить массу в кг и фунтах, но дату передавать в любом виде, кроме как ISO строка - идея так себе, поэтому обозначение в скобках просто избыточно
@@SuperOsa777 iso date format это подпись от меня, а не часть передаваемой строки :)
@@maslennikovvaleriy тогда окей, а то вдруг кто-то бы строкой это передавал...
Дизайн API: Совет 6 ( 14:57 ). С ним проблема. Со стороны клиента приложения - такой endpoint не особо полезен. Факт того что бакэнд приложение не работает, можно выяснить по любому запросу. Но это слабый аргумент. А вот сильный - что должно вернуться клиенту, если в момент запроса из 10 запущенных инстансов приложения бакэнда (за балансировщиком) 8 работает, 1 запускается, а 1 не работает? Где будет реализована логика проверки работает/не работает? В балансировщике? А как он поймёт, что от него программист приложения хочет? Вообще, health check лучше прятать от внешнего клиента и оставлять его доступным только(!) инфраструктурным клиентам, типа балансировщика.
@@DlinnyLag для получения статуса в целом по инфраструктуре используют Atlassian status или аналоги. А в целом, если у вас 10 инстансов и 2 не работают - это нормально, на то их и много. Для клиента это Healthy. В случае падения производительности из-за вывода инстансов можно сервису дать статус Degraded.
Шрифт какой-то знакомый...
Не Onest ли?
4:25
Почему нельзя конкретно назвать какой код должен вернутся для методов get, put, post, delete ? 201 код должен вернуть put или post ? Не сказано
Открой спецификацию http codes там все подробно описано.
201 это когда что-то создано успешно, например в базе данных заведен новый профиль. В абстракции не важно какой метод, главное что-то создано, но обычно это POST
Валерчик вставь таймкоды пожалуйста
0:03 Тема про API (не Web API).
0:33 Говорит о Web API, тут же называя его API.
1:04 говорит о WEB API.
1:24 Далее задается вопросом зачем нужно проектировать API (видимо имел ввиду WEB API), но объясняет зачем нужны API в принципе, перечисляя максимально абстрактные цели, причем на максимально далеком от практики примере.
5:14 "клиента отправляют к поддержке". Тут понятие клиент из архитектуры перепутано с понятием клиент из договора.
7:05 Говорит: "использование множественных чисел", имея ввиду существительные во множественном числе.
18:45 "масштабировать производительность" - одно слово лишнее.
Выглядит так, что все что нашел в интернете по ключевыми словами, то и написал, а то что это разные понятия с похожими ключевыми словами - это не так важно.
Мешанина из понятий Web API и API, клиентское приложение и клиент в юридическом смысле. Говорит об API, хотя имеет ввиду WEB API и прыгает с одного на другое.
Столько слов написано, а по делу ничего
Хорошее видео, но пример с идемпотентностью неправильный. DELETE должен возвращать одинаковый РЕЗУЛЬТАТ, а не изменять состояние системы. По REST у системы вообще не должно быть состояний. 6:24 как раз ошибочно будет вернуть 404 Not Found, если первый раз вернули 200/204.
Спасибо за комментарий, я рад, что видео понравилось :)
Не совсем согласен с вами, хотя возможно мне нужно было явно проговорить, что говоря об идемпотентности, я подразумеваю изменение состояния ресурсов. Тут важно различать термин "состояние" в разных контекстах:
1. В REST "stateless" отсылает к тому, что ответственность за хранение информации о текущей сессии и её состоянии между запросами несет не сервер, а клиент. Другими словами, 'отсутствие состояния' в контексте REST означает, что каждый запрос должен быть самодостаточным и не зависеть от предыдущих запросов. Но это не значит, что ресурсы REST API не могут иметь различных состояний: пользователь удалён, в бане, создан и т.п. Отсюда и следует возможность получать различные ответы в зависимости от различных состояний ресурсов API. Юзера удалили - теперь получили 404, так как состояние ресурса поменялось. Сервер при этом всё ещё не хранит никакого состояния между запросами, он всё ещё оперирует только ресурсами и ничего не знает о предыдущих запросах. Это и есть stateless из REST.
2. В контексте идемпотентности я как раз говорю о состоянии ресурсов, повторный запрос не должен их изменять. При этом свойство идемпотентности никак не регламентирует поведение сервера. То есть идемпотентное удаление может быть реализовано как с вариантом кода 200 в смысле "ресурс уже удалён", так и 404, т.к. ресурс уже удалён (к тому же, 200 не всегда возможен, ведь не всегда используется мягкое удаление).
Слабо, очень слабо. По сути контент ради контента, а тема не раскрыта вовсе.
Сначала автор лил воду, рассказывая что такое RestAPI, потом прошелся по про всем очевидные вещи, известные всем, такие так http заголовки и нейминг и даже там тему не раскрыл.
Во первых использовать get для модифицирующих операций нельзя в первую очередь из соображений безопасности, а не приверженности дизайну (я могу скинуть ссылку залогиненому пользователю и перейдя по ней он непроизвольно выполнит действие)
С неймингом все сложнее когда у вас нетривиальный пример ( нука скажите как должен выглядеть метод запуска ракеты )
Ну и самое главное, о чем не было сказано ни слова: одного rest недостаточно для спецификации, поэтому поверх него есть какая-нибудь OData или кастомный протокол, который единообразно описывает как должны выглядеть query params для фильтрации, респонсы с пагинацией и метаинформацией
Вам больше книжный формат подойдет :)
Ни про http методы, ни про связи ничего не сказано, т.е. для сферического апи в вакууме.
Ты видимо жопой смотрел.
Дам прямую ссылку на методы 3:50
13:45 Офсет-пагинация не улучшает производительность
Подскажите, пожалуйста, а как тогда быть? Попросить использовать параметр from_id? Это сделает поиск в MySQL, к примеру, быстрее, т.к. будут искаться записи по первичному ключу?
Ну ты малоумный конечно... Коречно лучше вернуть юзеру всю бд на 2 гига за раз, чтоб он потом еще раз обновил страницу и еще раз выкачал 2 гига, вместо 5 кб за условные 10 элементов. Может юзеру всего 30 элементов над будет увидеть до нужного результата
@@niknt Курсорная пагинация
Комментарий, видео кншн прям очень банальное, напихал те самые практики с водой, так еще и в рамках http, ну ладно, целевая аудитория вроде в восторге.
Балансировщик настроить еще надо. И запросы должны иметь липкие сессии, чтобы не ходили в другие сервера. Тут не все так просто. Это целый пласт инфы
Это две строчки кода)
@@popuguytheparrot_ спасибо за коммент!
Настроить - да, хотя сейчас есть куча готовых вариантов вроде HAProxy, где достаточно небольшого конфигурационного файла для начала балансировки. А липкие сессии не нужны, если вы придерживаетесь REST подхода, ведь он подразумевает, что сервер не хранит информацию о запросах между сессиями.
Кстати, в телеге расписал некоторые распространенные алгоритмы балансировки, если вдруг интересно :)
Мне кажется, лучше версионировать апи целиком
Тебе кажется.
Не всегда API меняется целиком, может поменяться один endpoint, а клиентом прийдётся переписывать все интеграции вместо одной
Это оба способа используются. Но чтоб было более порядочно, лучше версию давать всему приложению и если выходит новая версия например с 1.1.1 на 2.0.0 это означает что приложение имеет необратимые изменения, то есть чтоб поддерживать старых клиентов, нужно чтоб обе версии работали и передавать например header с той версией которая нужна клиенту. Ну а старую версию deprecate с датой, чтоб клиенты успели мигрировать до того как старую версию можно shutdown.
Ну рт хорошей ддос-атаки тротлинг не поможет😅
Посмотрел 1-ю минуту видео и уже там введение людей в заблуждение: REST - это не только HTTP и даже не обязательно HTTP. Транспортом может быть что угодно.
Если уж с первоисточниками не сложилось, то хотя бы 1-й абзац русской википедии стоило прочитать.
Так а на чем работает большинство API?
Ответ будет HTTP. В Википедии про это не написали?
слушайте, где вы берете это‘аш’ в http, что это вообще аш ? аш мля 😅
Старая привычка, но вы правы :)
А когда мне нужно получить ресурс через POST а не через GET то как назвать без глагола что это get))
А какие причины для получения ресурса через POST? Случайно, не передача параметров в body вместо query string?
@xdFOrfq8VVH6j5kXAh использование json схемы, запросы не являются идемподентными. Естественно передача параметров в body так длинна через get не позволяет.
@xdFOrfq8VVH6j5kXAh Мне вообще get не получается применять, в редких простых случаях. И то забиваешь на них и тоже через post делаешь. Но за видео спасибо, вроде толково рассказал. Но вот как проблему с post решить пока не понял.
@@Alex89muller интересно, а что за данные такие длинные, что нельзя их в параметры гета запихнуть?
@@l33ncore История переписки с ии. Вообще по правильному думаю для нее нужно наверно что типа redis поднимать. Но я пока rest гружу и бл. я там не выходит. Ну и плюсом там приходится масса других параметров передавать. Get не удобен.
Кликбейт…
В названии должно быть webApi а не api
🫠
И тут аштитипи. Какое аш, вы поехавшие все что ли?
Гифка "Да что ты черт побери такое несешь?" на первом же совету по неймингу
Поделитесь, что вас так возмутило?)
Вот я тоже не понял
@@maslennikovvaleriy Когда ты получаешь одну сущность по ID, то это плохая идея делать путь во множественном числе, а у тебя наоборот. Да, для API это не критично на самом деле, потому как пользователи не видят URL, но для остального стоит всё же логичные URL.
@@maslennikovvaleriyне обращай внимания, все правильно.
А вы, наверно, в синем/красном банке работаете, да?
а почему «продукт не найден»
с кодом 404 ? это же недоступность ресурса