Просто один из примеров того, как надо записывать обзорные видео. Кратко, схематично, очень последовательно. Просто снимаю шляпу, автору лайк, подписка и в сохраненные. Как аниматор со стажем, хочу отметить ещё и анимационный подход. Всё минималистично, плавно и к месту.
Очень качественный материал, спасибо за потраченное на создание время! Я по профессии QA, мне оказалось полезным, то что надо, чтобы разложить разрозненные знания по полочкам и вспомнить то, что знаю, но забыл!
Очень хорошо объяснил, для новичков я бы ещё добавил картинки запросов, ответов с заголовками, чтобы было понятно где находится код, используемый метод и т.д. Curl их обычно в консоль выкидывает по запросу.
на 1:10 приведена некорректная таблица. Единственное что в ней является архитектурным стилем - это REST. В целом, если эта информация от начинающего разработчика без какого либо бэкграунда - то в целом, ок. Но надо иметь в виду что приведет людей к заблуждению в терминологии, как минимум.
Видео понравилось, подача отличная, спасибо за Ваш труд. Считаю бы лучше если помимо самих советов указывать еще и статьи/литературу на чем они основываются. Так помимо информации даваемой Вами можно будет еще и получить углубленное понимание 😀
Спасибо. Добавьте пункт об описании интерфейса API. По запросу, например get=options пользователь должен получить инструкции (help) о ключах и методах.
По хорошему, у каждого приложения должен быть GET /entrypoint - входная точка, которая выдает массив объектов «гиперссылок» с полями title, method, href, rel добавить можно хоть что но есть стандарты у каждой компании. В этом массиве всегда есть ссылки и описание чтоб клиенты (к примеру reactjs) могли парсить их для того что бы понять куда отправлять запрос дальше, как только ссылка отпределена и запрос сделан, далее в ответе вместе с данными, должен быть снова массив links где так же ссылки на то что дальше можно сделать, и так может быть бесконечно, то есть API дает знать клиентам о том как оно работает.
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 и прыгает с одного на другое.
Отдельно напишу коммент по содержанию. Все обстоятельно. Мне не хватило, пожалуй, про передачу данных. В каком случае это делать в заголовках, в каком - в теле запроса, в каком - через адресную строку. Я знаю мало, и мне бывает интересно, почему одни полагаются на заголовки, а другие на 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
11:05 Как парсить потом форматы дат? У нас на входе строка с содержимым 2023-03-15 (...Хоть что...) Не проще передавать сразу ISO строку без дополнительных единиц измерения? (ну и конечно применить валидацию на ISO строку) Мы можем измерить массу в кг и фунтах, но дату передавать в любом виде, кроме как ISO строка - идея так себе, поэтому обозначение в скобках просто избыточно
Недавно разрабатывал свое первое REST API приложение, сейчас наткнулся на ваше видео и понял что уже с нуля разрабатывал его по лучшим практикам, но из видео стало ясно чего не хватало. На каком языке вы разрабатываете?
Открой спецификацию http codes там все подробно описано. 201 это когда что-то создано успешно, например в базе данных заведен новый профиль. В абстракции не важно какой метод, главное что-то создано, но обычно это POST
Дизайн api совет 4. Ремарка, понятное описание должно быть на всем кроме авторизации. Не нужно говорить пользователю что он ввел пароль не верно. Лучше писать, что логин или пароль были введены неправильно, так вы повысите безопасность системы
Подскажите, пожалуйста, а как тогда быть? Попросить использовать параметр from_id? Это сделает поиск в MySQL, к примеру, быстрее, т.к. будут искаться записи по первичному ключу?
Хорошее видео, но пример с идемпотентностью неправильный. DELETE должен возвращать одинаковый РЕЗУЛЬТАТ, а не изменять состояние системы. По REST у системы вообще не должно быть состояний. 6:24 как раз ошибочно будет вернуть 404 Not Found, если первый раз вернули 200/204.
Спасибо за комментарий, я рад, что видео понравилось :) Не совсем согласен с вами, хотя возможно мне нужно было явно проговорить, что говоря об идемпотентности, я подразумеваю изменение состояния ресурсов. Тут важно различать термин "состояние" в разных контекстах: 1. В REST "stateless" отсылает к тому, что ответственность за хранение информации о текущей сессии и её состоянии между запросами несет не сервер, а клиент. Другими словами, 'отсутствие состояния' в контексте REST означает, что каждый запрос должен быть самодостаточным и не зависеть от предыдущих запросов. Но это не значит, что ресурсы REST API не могут иметь различных состояний: пользователь удалён, в бане, создан и т.п. Отсюда и следует возможность получать различные ответы в зависимости от различных состояний ресурсов API. Юзера удалили - теперь получили 404, так как состояние ресурса поменялось. Сервер при этом всё ещё не хранит никакого состояния между запросами, он всё ещё оперирует только ресурсами и ничего не знает о предыдущих запросах. Это и есть stateless из REST. 2. В контексте идемпотентности я как раз говорю о состоянии ресурсов, повторный запрос не должен их изменять. При этом свойство идемпотентности никак не регламентирует поведение сервера. То есть идемпотентное удаление может быть реализовано как с вариантом кода 200 в смысле "ресурс уже удалён", так и 404, т.к. ресурс уже удалён (к тому же, 200 не всегда возможен, ведь не всегда используется мягкое удаление).
Это оба способа используются. Но чтоб было более порядочно, лучше версию давать всему приложению и если выходит новая версия например с 1.1.1 на 2.0.0 это означает что приложение имеет необратимые изменения, то есть чтоб поддерживать старых клиентов, нужно чтоб обе версии работали и передавать например header с той версией которая нужна клиенту. Ну а старую версию deprecate с датой, чтоб клиенты успели мигрировать до того как старую версию можно shutdown.
@@popuguytheparrot_ спасибо за коммент! Настроить - да, хотя сейчас есть куча готовых вариантов вроде HAProxy, где достаточно небольшого конфигурационного файла для начала балансировки. А липкие сессии не нужны, если вы придерживаетесь REST подхода, ведь он подразумевает, что сервер не хранит информацию о запросах между сессиями. Кстати, в телеге расписал некоторые распространенные алгоритмы балансировки, если вдруг интересно :)
@xdFOrfq8VVH6j5kXAh использование json схемы, запросы не являются идемподентными. Естественно передача параметров в body так длинна через get не позволяет.
@xdFOrfq8VVH6j5kXAh Мне вообще get не получается применять, в редких простых случаях. И то забиваешь на них и тоже через post делаешь. Но за видео спасибо, вроде толково рассказал. Но вот как проблему с post решить пока не понял.
@@nikitakehlerr311 История переписки с ии. Вообще по правильному думаю для нее нужно наверно что типа redis поднимать. Но я пока rest гружу и бл. я там не выходит. Ну и плюсом там приходится масса других параметров передавать. Get не удобен.
Посмотрел 1-ю минуту видео и уже там введение людей в заблуждение: REST - это не только HTTP и даже не обязательно HTTP. Транспортом может быть что угодно. Если уж с первоисточниками не сложилось, то хотя бы 1-й абзац русской википедии стоило прочитать.
Слабо, очень слабо. По сути контент ради контента, а тема не раскрыта вовсе. Сначала автор лил воду, рассказывая что такое RestAPI, потом прошелся по про всем очевидные вещи, известные всем, такие так http заголовки и нейминг и даже там тему не раскрыл. Во первых использовать get для модифицирующих операций нельзя в первую очередь из соображений безопасности, а не приверженности дизайну (я могу скинуть ссылку залогиненому пользователю и перейдя по ней он непроизвольно выполнит действие) С неймингом все сложнее когда у вас нетривиальный пример ( нука скажите как должен выглядеть метод запуска ракеты ) Ну и самое главное, о чем не было сказано ни слова: одного rest недостаточно для спецификации, поэтому поверх него есть какая-нибудь OData или кастомный протокол, который единообразно описывает как должны выглядеть query params для фильтрации, респонсы с пагинацией и метаинформацией
Комментарий, видео кншн прям очень банальное, напихал те самые практики с водой, так еще и в рамках http, ну ладно, целевая аудитория вроде в восторге.
@@maslennikovvaleriy Когда ты получаешь одну сущность по ID, то это плохая идея делать путь во множественном числе, а у тебя наоборот. Да, для API это не критично на самом деле, потому как пользователи не видят URL, но для остального стоит всё же логичные URL.
Просто один из примеров того, как надо записывать обзорные видео. Кратко, схематично, очень последовательно. Просто снимаю шляпу, автору лайк, подписка и в сохраненные. Как аниматор со стажем, хочу отметить ещё и анимационный подход. Всё минималистично, плавно и к месту.
@@practical-skills-school больше спасибо!
Согласен, как шпаргалка для разработчика
Спасибо! Я фронтенд-разработчик, мимо проходил) Видео понравилось, четко структурировано, понятно и с примерами.
Очень качественный материал, спасибо за потраченное на создание время! Я по профессии QA, мне оказалось полезным, то что надо, чтобы разложить разрозненные знания по полочкам и вспомнить то, что знаю, но забыл!
Один из лучших видосов что я смотрел по теме, крайне приятно смотреть и крайне полезно, прям хочется сделать шпаргалку
@@extressar679 спасибо!
Буду использовать как "настольную книгу" и пересматривать каждый, раз когда буду начинать новый проект, спасибо!
Спасибо, неплохо было проговорить все это в качестве напоминания
Ппц, чуть не начал писать а тут такое... "дизайн апи" , прям оч вовремя, спс огромное.
Очень хорошее видео. Без воды и с приятным визуалом ❤
Очень круто, молодец. Спасибо большое
Если добавить таймкоды, чтобы можно было возвращаться к видео время от времени, то вообще огонь будет
Одно из тех немногих видео, которое я досмотрел до конца. Спасибо!
Супер полезное видео. Буду теперь всех джунов сюда отсылать, чтобы не объяснять самому одно и тоже.
Очень хорошо объяснил, для новичков я бы ещё добавил картинки запросов, ответов с заголовками, чтобы было понятно где находится код, используемый метод и т.д. Curl их обычно в консоль выкидывает по запросу.
Аналогия с всратым рестораном это угар. Топ, видно, что постарался над видео!
Спасибо за информативный и познавательный контент! Привет из солнечного Узбекистана🇺🇿
Привет! И вам спасибо :)
Очень классный визуал. Не планировал просвещаться в этой теме, но визуал так зацепил, что не могу оторваться )
Спасибо! Как раз тестировал формат, рад фидбеку 🙂
Сделайте видео как и где правильно использовать exceptions
Очень приятно было-бы видеть тайм-коды, на тайм лайне))
Видео огонь! Грамотная подача, четкий визуал, все по сущетсву, спасибо!
Удобно, скрншотами можно сохраннять советы
на 1:10 приведена некорректная таблица. Единственное что в ней является архитектурным стилем - это REST. В целом, если эта информация от начинающего разработчика без какого либо бэкграунда - то в целом, ок. Но надо иметь в виду что приведет людей к заблуждению в терминологии, как минимум.
Всё вроде очевидно, но приятно еще раз послушать
Спасибо, очень четко! Помог разобраться.
Очень полезное видео для меня. Слайды супер. Спасибо! 👍👍👍
Жду с нетерпением новых видео.
То самое видео, которое досмотрел до конца. Хорошо
Спасибо, интересно, полезно, без воды! Лайк, подписка и колокольчик 💪
Большое вам спасибо за такое полезное видео! Очень понравилось 😊
Ждем видос про виды кеширования и подходы!!!
Прекрасное видео! Спасибо большое, жду ещё подобные видео.
Видео понравилось, подача отличная, спасибо за Ваш труд. Считаю бы лучше если помимо самих советов указывать еще и статьи/литературу на чем они основываются. Так помимо информации даваемой Вами можно будет еще и получить углубленное понимание 😀
Спасибо. Добавьте пункт об описании интерфейса API. По запросу, например get=options пользователь должен получить инструкции (help) о ключах и методах.
По хорошему, у каждого приложения должен быть GET /entrypoint - входная точка, которая выдает массив объектов «гиперссылок» с полями title, method, href, rel добавить можно хоть что но есть стандарты у каждой компании. В этом массиве всегда есть ссылки и описание чтоб клиенты (к примеру reactjs) могли парсить их для того что бы понять куда отправлять запрос дальше, как только ссылка отпределена и запрос сделан, далее в ответе вместе с данными, должен быть снова массив links где так же ссылки на то что дальше можно сделать, и так может быть бесконечно, то есть API дает знать клиентам о том как оно работает.
Отличное видео! Очень полезно.
Если бы у всех туториалов была такая подача, у нас бы уже были летающие машины
Ахаха, спасибо!
Спасибо за видео, очень полезно )
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 и прыгает с одного на другое.
Отличное видео! Поддерживаю!
Отличный видос!
Стоило рассказать, где имеет смысл применять Rest, особенно соответствующий Restful
Отдельно напишу коммент по содержанию. Все обстоятельно. Мне не хватило, пожалуй, про передачу данных. В каком случае это делать в заголовках, в каком - в теле запроса, в каком - через адресную строку. Я знаю мало, и мне бывает интересно, почему одни полагаются на заголовки, а другие на 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 подстроят их так , что их переатанет срезать.
Пожалуйста сделай видео про OAuth 2.0
11:05
Как парсить потом форматы дат?
У нас на входе строка с содержимым 2023-03-15 (...Хоть что...)
Не проще передавать сразу ISO строку без дополнительных единиц измерения? (ну и конечно применить валидацию на ISO строку)
Мы можем измерить массу в кг и фунтах, но дату передавать в любом виде, кроме как ISO строка - идея так себе, поэтому обозначение в скобках просто избыточно
@@SuperOsa777 iso date format это подпись от меня, а не часть передаваемой строки :)
@@maslennikovvaleriy тогда окей, а то вдруг кто-то бы строкой это передавал...
Недавно разрабатывал свое первое REST API приложение, сейчас наткнулся на ваше видео и понял что уже с нуля разрабатывал его по лучшим практикам, но из видео стало ясно чего не хватало. На каком языке вы разрабатываете?
@@exoneges C# чаще всего, иногда JS, если надо быстро сделать что-то маленькое
Почему Джарахов рассказывает про api?
4:25
Почему нельзя конкретно назвать какой код должен вернутся для методов get, put, post, delete ? 201 код должен вернуть put или post ? Не сказано
Открой спецификацию http codes там все подробно описано.
201 это когда что-то создано успешно, например в базе данных заведен новый профиль. В абстракции не важно какой метод, главное что-то создано, но обычно это POST
Дизайн api совет 4. Ремарка, понятное описание должно быть на всем кроме авторизации. Не нужно говорить пользователю что он ввел пароль не верно. Лучше писать, что логин или пароль были введены неправильно, так вы повысите безопасность системы
Согласен :)
Валерчик вставь таймкоды пожалуйста
13:45 Офсет-пагинация не улучшает производительность
Подскажите, пожалуйста, а как тогда быть? Попросить использовать параметр from_id? Это сделает поиск в MySQL, к примеру, быстрее, т.к. будут искаться записи по первичному ключу?
Хорошее видео, но пример с идемпотентностью неправильный. DELETE должен возвращать одинаковый РЕЗУЛЬТАТ, а не изменять состояние системы. По REST у системы вообще не должно быть состояний. 6:24 как раз ошибочно будет вернуть 404 Not Found, если первый раз вернули 200/204.
Спасибо за комментарий, я рад, что видео понравилось :)
Не совсем согласен с вами, хотя возможно мне нужно было явно проговорить, что говоря об идемпотентности, я подразумеваю изменение состояния ресурсов. Тут важно различать термин "состояние" в разных контекстах:
1. В REST "stateless" отсылает к тому, что ответственность за хранение информации о текущей сессии и её состоянии между запросами несет не сервер, а клиент. Другими словами, 'отсутствие состояния' в контексте REST означает, что каждый запрос должен быть самодостаточным и не зависеть от предыдущих запросов. Но это не значит, что ресурсы REST API не могут иметь различных состояний: пользователь удалён, в бане, создан и т.п. Отсюда и следует возможность получать различные ответы в зависимости от различных состояний ресурсов API. Юзера удалили - теперь получили 404, так как состояние ресурса поменялось. Сервер при этом всё ещё не хранит никакого состояния между запросами, он всё ещё оперирует только ресурсами и ничего не знает о предыдущих запросах. Это и есть stateless из REST.
2. В контексте идемпотентности я как раз говорю о состоянии ресурсов, повторный запрос не должен их изменять. При этом свойство идемпотентности никак не регламентирует поведение сервера. То есть идемпотентное удаление может быть реализовано как с вариантом кода 200 в смысле "ресурс уже удалён", так и 404, т.к. ресурс уже удалён (к тому же, 200 не всегда возможен, ведь не всегда используется мягкое удаление).
Мне кажется, лучше версионировать апи целиком
Тебе кажется.
Не всегда API меняется целиком, может поменяться один endpoint, а клиентом прийдётся переписывать все интеграции вместо одной
Это оба способа используются. Но чтоб было более порядочно, лучше версию давать всему приложению и если выходит новая версия например с 1.1.1 на 2.0.0 это означает что приложение имеет необратимые изменения, то есть чтоб поддерживать старых клиентов, нужно чтоб обе версии работали и передавать например header с той версией которая нужна клиенту. Ну а старую версию deprecate с датой, чтоб клиенты успели мигрировать до того как старую версию можно shutdown.
Балансировщик настроить еще надо. И запросы должны иметь липкие сессии, чтобы не ходили в другие сервера. Тут не все так просто. Это целый пласт инфы
Это две строчки кода)
@@popuguytheparrot_ спасибо за коммент!
Настроить - да, хотя сейчас есть куча готовых вариантов вроде HAProxy, где достаточно небольшого конфигурационного файла для начала балансировки. А липкие сессии не нужны, если вы придерживаетесь REST подхода, ведь он подразумевает, что сервер не хранит информацию о запросах между сессиями.
Кстати, в телеге расписал некоторые распространенные алгоритмы балансировки, если вдруг интересно :)
Ну рт хорошей ддос-атаки тротлинг не поможет😅
Ни про http методы, ни про связи ничего не сказано, т.е. для сферического апи в вакууме.
Ты видимо жопой смотрел.
Дам прямую ссылку на методы 3:50
А когда мне нужно получить ресурс через POST а не через GET то как назвать без глагола что это get))
А какие причины для получения ресурса через POST? Случайно, не передача параметров в body вместо query string?
@xdFOrfq8VVH6j5kXAh использование json схемы, запросы не являются идемподентными. Естественно передача параметров в body так длинна через get не позволяет.
@xdFOrfq8VVH6j5kXAh Мне вообще get не получается применять, в редких простых случаях. И то забиваешь на них и тоже через post делаешь. Но за видео спасибо, вроде толково рассказал. Но вот как проблему с post решить пока не понял.
@@Alex89muller интересно, а что за данные такие длинные, что нельзя их в параметры гета запихнуть?
@@nikitakehlerr311 История переписки с ии. Вообще по правильному думаю для нее нужно наверно что типа redis поднимать. Но я пока rest гружу и бл. я там не выходит. Ну и плюсом там приходится масса других параметров передавать. Get не удобен.
Посмотрел 1-ю минуту видео и уже там введение людей в заблуждение: REST - это не только HTTP и даже не обязательно HTTP. Транспортом может быть что угодно.
Если уж с первоисточниками не сложилось, то хотя бы 1-й абзац русской википедии стоило прочитать.
Так а на чем работает большинство API?
Ответ будет HTTP. В Википедии про это не написали?
слушайте, где вы берете это‘аш’ в http, что это вообще аш ? аш мля 😅
Старая привычка, но вы правы :)
Кликбейт…
В названии должно быть webApi а не api
🫠
Слабо, очень слабо. По сути контент ради контента, а тема не раскрыта вовсе.
Сначала автор лил воду, рассказывая что такое RestAPI, потом прошелся по про всем очевидные вещи, известные всем, такие так http заголовки и нейминг и даже там тему не раскрыл.
Во первых использовать get для модифицирующих операций нельзя в первую очередь из соображений безопасности, а не приверженности дизайну (я могу скинуть ссылку залогиненому пользователю и перейдя по ней он непроизвольно выполнит действие)
С неймингом все сложнее когда у вас нетривиальный пример ( нука скажите как должен выглядеть метод запуска ракеты )
Ну и самое главное, о чем не было сказано ни слова: одного rest недостаточно для спецификации, поэтому поверх него есть какая-нибудь OData или кастомный протокол, который единообразно описывает как должны выглядеть query params для фильтрации, респонсы с пагинацией и метаинформацией
Вам больше книжный формат подойдет :)
Комментарий, видео кншн прям очень банальное, напихал те самые практики с водой, так еще и в рамках http, ну ладно, целевая аудитория вроде в восторге.
Гифка "Да что ты черт побери такое несешь?" на первом же совету по неймингу
Поделитесь, что вас так возмутило?)
Вот я тоже не понял
@@maslennikovvaleriy Когда ты получаешь одну сущность по ID, то это плохая идея делать путь во множественном числе, а у тебя наоборот. Да, для API это не критично на самом деле, потому как пользователи не видят URL, но для остального стоит всё же логичные URL.
@@maslennikovvaleriyне обращай внимания, все правильно.
А вы, наверно, в синем/красном банке работаете, да?