วีดีโอ

Дизайн API: Совет 6 ( 14:57 ). С ним проблема. Со стороны клиента приложения - такой endpoint не особо полезен. Факт того что бакэнд приложение не работает, можно выяснить по любому запросу. Но это слабый аргумент. А вот сильный - что должно вернуться клиенту, если в момент запроса из 10 запущенных инстансов приложения бакэнда (за балансировщиком) 8 работает, 1 запускается, а 1 не работает? Где будет реализована логика проверки работает/не работает? В балансировщике? А как он поймёт, что от него программист приложения хочет? Вообще, health check лучше прятать от внешнего клиента и оставлять его доступным только(!) инфраструктурным клиентам, типа балансировщика.

а почему «продукт не найден» с кодом 404 ? это же недоступность ресурса

Шрифт какой-то знакомый... Не Onest ли?

Это лучшее объяснение! Спасибо!

Молодец бро

Я использовал users - выдача всех пользователей, а user/{id} отдача конкретного. И посчитал что так интуитивнее понятнее) Но сейчас понимаю, что по сути и верно было множественное и из него выборка уже... Но уже 3 версии продукта прошло и менять этого конечно никто не будет

А еще лучше использовать кебаб кейс, вместо кемел или снейк кейса. Это банально красивее выглядит в пути эндпоинта

Что не понятного в GET/ POST /delete/{id}? Что прям limit и offset? Это sql понятия. Почему не page и size?

По поводу ошибок на 4 минуте - вообще не согласен. Если у тебя очень много ошибок, для которых не всегда подходит тот или иной код http, то лучше и проще всегда отдавать 200 код, который символизирует, что запрос был обраюотан, если нет -500, а далее уже смотрим в тело ответа и отдаём клиенту. Пример такой реализации использует Cloudflare и др компании

Отличное видео, спасибо за работу. Вроде большинство из этого уже известно, но из-за того что опыта пока мало все в голове тяжело удержать, надо периодически повторять :)

Про коды - откровенная лажа. Эти коды относятся к веб-серверу. Если код дошел до обработчика - никакого ответа кроме 200 быть не должно. Почему? Потому что опять - а как твой клиент поймет, это 404 из-за того что nginx на балансировщике отдал, или юзера нет в БД? А никак, он все равно должен будет полезть в тело. А если он и так лезет в тело - на кой фиг ты отдаешь код который относится фиг пойми к чему? Вот зачем? Вот что ты этим хочешь достичь? Далее, вся эта фигня с "рестфул" ведет к тому, что у тебя по сути каждый эндпоинт может разный формат сообщения отдать, ведь с точки зрения рест - это разные ресурсы. Офигенно же. В результате - у тебя юзеры отдаются так, товары эдак, а теги вот так вот. Это конечно в крайнем случае, но не суть. А суть в том, что не натягивайте HTTP на приложение. Оно не для этого придумано, протокол HTTP придуман для веб-сервера непосредственно, ваше приложение - оно уже за веб-сервером. У него должны быть свои коды. И если до вас дошел запрос - альтернативы кроме как отдать 200 быть не должно. Потому что - ну, а чего бы тогда коды TCP для информирования об ошибках не использовать? Шли RST и кайфуй) Плюс - дальше - ваше приложение надо будет выносить за HTTP, на какой-нибудь jsonRPC или еще что-то. Че делать будем? Переделывать половину инфраструктурной части, чтобы тот же, в рамках приложения, но отличающийся транспортом запрос? Ну не бред ли? Короче. Пилишь веб-сервер - используешь коды HTTP для ответа. Если пилишь приложение - всегда возвращаешь 200 и не насилуешь мозги ни себе ни людям.

Пожалуйста делай по больше таких видео, не концентрируйся на C#)

Про безопасность. Работали с одним сервисом, и нам нужно было получить список их пользователей. Там было два эндпоинта, один возвращает только имя, id, и несколько вспомогательных полей, а второй возвращает вообще все, вплоть до паспортных данных. Мне их разработчик говорит, вот вам токен авторизации, вам нужно использовать только первый эндпоинт, а я просто для интереса попробовал использовать второй, и да, я просто получил список их пользователь с кучей конфедециальной информации. Побежали исправлять, оказалось, что "ограниченные" токены авторизации, которые они дают своим партнёрам, давали доступ АБСОЛЮТНО ко всему.

Очень круто! Кликнул на видео с мыслью освежить знания и не пожалел, структурированно и по делу, подписался :)

Глаголы это, конечно, хорошо, но в крупных проектах лучше всего подходит json Api, пост на всё и 200 на всё, а ошибки в теле ответа. Да и вообще grpc намного удобнее, особенно если сервисов дохрена. Работаю в бигтехе, знаю о чем говорю.

И тут аштитипи. Какое аш, вы поехавшие все что ли?

Вместе с 429 принято возвращать заголовок Retry-After, который идет по стандарту. Так многие клиенты смогут автоматически подождать и не перенастраивать на ваши кастомные заголовки

Пишу для продвижения канала автора, выпуск огонь, учитывая что основной стек в контентенте не интересен. Даешь больше тем по архитектуре, бд и т.д.

Я хз кто ты, но ты хорош. Все что хотел сказать, но не мог сформулировать

Спасибо, неплохо было проговорить все это в качестве напоминания

11:05 Как парсить потом форматы дат? У нас на входе строка с содержимым 2023-03-15 (...Хоть что...) Не проще передавать сразу ISO строку без дополнительных единиц измерения? (ну и конечно применить валидацию на ISO строку) Мы можем измерить массу в кг и фунтах, но дату передавать в любом виде, кроме как ISO строка - идея так себе, поэтому обозначение в скобках просто избыточно

Стоило рассказать, где имеет смысл применять Rest, особенно соответствующий Restful

Как-то сумбурно В начале написано restful, а описывается rest api, игнорируя последние три буквы . При этом первым пунктом в бестпрактис - это используйте GET/POST/PUT/DELETE - а это собственно есть последние три буквы. Т.е. REST - это формат обмена, т.е. json поверх HTTP, а RESTful - это уже способ проектирования апи, на основе REST. Кэширование - не являются частью API, как и Rate Limiter, тоже не являются, но раз уж о них, то где circuit breaker? Про пароли в теле запроса, дело ни в том, что в теле запроса оно лежит безопасней, тело запроса точно также логируется на проксисервере, там в целом весь запрос логируется, дело в том, что во первых метод логина - не иденпотентен и не может быть GET по условиям RESTful, а во вторых - дело в том, что методы GET и POST обычно имеют разную политику обработки на уровне маршрутизации и безопасности (даже на уровне CORS это сделано). Если авторизация сделана через GET, логин и пароль можно увести через простую ссылку, хоть на картинку в обычном html

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 и прыгает с одного на другое.

Очень качественный материал, спасибо за потраченное на создание время! Я по профессии QA, мне оказалось полезным, то что надо, чтобы разложить разрозненные знания по полочкам и вспомнить то, что знаю, но забыл!

Удобно, скрншотами можно сохраннять советы

Один из лучших видосов что я смотрел по теме, крайне приятно смотреть и крайне полезно, прям хочется сделать шпаргалку

Если бы у всех туториалов была такая подача, у нас бы уже были летающие машины

Недавно разрабатывал свое первое REST API приложение, сейчас наткнулся на ваше видео и понял что уже с нуля разрабатывал его по лучшим практикам, но из видео стало ясно чего не хватало. На каком языке вы разрабатываете?

Спасибо за видео, очень полезно )

Самое главное это делать спецификацию до имплементации. Например использовать openAPI (swagger) где все подробно описать, какой запрос и какой ответ ожидать. Так же делать маппинг документ где четко документированы детали и диаграмма операций каждого ендпойнта, это очень поможет клиентам вашего приложения и разработчикам. Без этой основы, в коде будет бардак и чем дальше, тем больше спагетти кода появится, дольше добавлять нововведения и создавать дополнительные баги.

17:30 - вот так делать не надо точно. Атакующие зная значения rate limit подстроят их так , что их переатанет срезать.

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

Спасибо! Я фронтенд-разработчик, мимо проходил) Видео понравилось, четко структурировано, понятно и с примерами.

Сделайте видео как и где правильно использовать exceptions

Спасибо, очень четко! Помог разобраться.

Почему Джарахов рассказывает про api?

Супер полезное видео. Буду теперь всех джунов сюда отсылать, чтобы не объяснять самому одно и тоже.

слушайте, где вы берете это‘аш’ в http, что это вообще аш ? аш мля 😅

Не очень согласен с советом об иерархической связи ресурсов. Реальный пример: был проект интернет-магазин. В нем были категории, в категориях продукты, в продуктах вариации, в вариациях характеристики. Гет на получение характеристик выглядел так: GET /categories/{id}/products/{id}/variations/{id}/specifications Здесь лишь последний айди реально имеет смысл - айди вариации продукта. Проверять правильность иерархии на бэкэнде не было смысла, поэтому просто брался последний айди и по нему шел запрос в базу данных, а вот с точки зрения фронта необходимость поддерживать 3 айди выливалась в бесполезный код. Поэтому решили остановиться на более простом варианте: GET /product-specifications?variation_id={id}

Спасибо, интересно, полезно, без воды! Лайк, подписка и колокольчик 💪

Большое вам спасибо за такое полезное видео! Очень понравилось 😊

Спасибо за информативный и познавательный контент! Привет из солнечного Узбекистана🇺🇿

Буду использовать как "настольную книгу" и пересматривать каждый, раз когда буду начинать новый проект, спасибо!

Отдельно напишу коммент по содержанию. Все обстоятельно. Мне не хватило, пожалуй, про передачу данных. В каком случае это делать в заголовках, в каком - в теле запроса, в каком - через адресную строку. Я знаю мало, и мне бывает интересно, почему одни полагаются на заголовки, а другие на body. И например, гет- запросы не должны передавать данные в теле, хотя такое технически возможно.

Просто один из примеров того, как надо записывать обзорные видео. Кратко, схематично, очень последовательно. Просто снимаю шляпу, автору лайк, подписка и в сохраненные. Как аниматор со стажем, хочу отметить ещё и анимационный подход. Всё минималистично, плавно и к месту.

Слабо, очень слабо. По сути контент ради контента, а тема не раскрыта вовсе. Сначала автор лил воду, рассказывая что такое RestAPI, потом прошелся по про всем очевидные вещи, известные всем, такие так http заголовки и нейминг и даже там тему не раскрыл. Во первых использовать get для модифицирующих операций нельзя в первую очередь из соображений безопасности, а не приверженности дизайну (я могу скинуть ссылку залогиненому пользователю и перейдя по ней он непроизвольно выполнит действие) С неймингом все сложнее когда у вас нетривиальный пример ( нука скажите как должен выглядеть метод запуска ракеты ) Ну и самое главное, о чем не было сказано ни слова: одного rest недостаточно для спецификации, поэтому поверх него есть какая-нибудь OData или кастомный протокол, который единообразно описывает как должны выглядеть query params для фильтрации, респонсы с пагинацией и метаинформацией

Прекрасное видео! Спасибо большое, жду ещё подобные видео.

Балансировщик настроить еще надо. И запросы должны иметь липкие сессии, чтобы не ходили в другие сервера. Тут не все так просто. Это целый пласт инфы

Очень хорошо объяснил, для новичков я бы ещё добавил картинки запросов, ответов с заголовками, чтобы было понятно где находится код, используемый метод и т.д. Curl их обычно в консоль выкидывает по запросу.