Разбираюсь в API крутых команд
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
Супер тема, надеюсь дальше будешь продолжать подобное. Это не какие-то библиотечки одногодки, это основа, которой на ютубе мало, потому что не хайповая.
посмотрел и понял что это не про построение а про то как сделано описание АПИ )))
Там вообще про АПИ ни слова, там про API.
По Salesforce не соглашусь. Соер говорит про неконсистентное API без примеров, что "это не страшный технический долг и продолжение от этого падать не будет". Таки будет, потому что клиентское приложение писать становится сложнее - нет примеров. Возможно, у них документация этот вопрос закрывает, но всё же иметь примеры ручек упрощает жизнь и уменьшает двусмысленность
На счет POST не соглашусь, а именно что можно использовать POST как признак, что тут создается ресурс, так как POST не всегда означает создание ресурса, POST может быть использован для получения ресурсов с передачей различных параметров в теле (body), которое в случае с GET не передается. Например, так
POST /tasks/search
{
where: {
name: {
contains: "change bulb"
}
}
}
в этом случае POST может быть использован для получения списка задач, отфильтрованных по имени
Swagger надо, чтоб был источник актуальных данных. Ну и чтоб разработчики его исправно вели )
Ну или чтоб кто-то один отвечал за обновление коллекции Постман и ее расшаривал на общем ресурсе )
кто мне объяснит, почему все делают частичное редактирование ресурса через PUT, а не PATCH? PUT - это замена (полностью) существующего ресурса другим (либо идемпотентное создание, если ресурс не существует), PATCH - частичное обновление. приведу пример: есть ресурс {id:1, name:Test}, мы хотим заменить имя на "NewTest". после PUT {name:NewTest}, ресурс будет равен: {name:NewTest}. после PATCH {name:NewTest}, ресурс равен: {id:1, name:NewTest}.
Тоже задавался данным вопросом
Введи в поиске "Why would you use PUT instead of PATCH?". Первым делом должна появиться страничка с StackOverFlow. Там описано. Если коротко - пользоваться PUT безопаснее, чем PATCH, потому что PUT идемпотентен, а PATCH - нет и может иметь сайд эффекты.
нашел ответ в статье "Please. Don't Patch Like That.". метод PATCH в теле запроса несет не данные ресурса, а операции, которые нужно сделать с ресурсом для его обновления (пример есть в статье).
@@sancocaparelli9732 Как сделает бекендщик. так и будет, с-без сайдэффектов. Гугл. н-р, почти везде в своих апи юзает patch
Он просто не вписывается в концепцию REST, использовать/не использовать - это на плечах архитектора, в зависимости от требуемых задач.
Спасибо за очень хорошое объяснение!
Спасибо
все до 2х сотой являются положительным ответом и можно экономить ресурсы используя резервы от 200 до 299
Спасибо за видео. Коммент в поддержку!
Огромное спасибо за информацию!
А как проектировать АПИ, если заранее не известна структура? Например: вначале есть физическое лицо, продажа и запрос. Потом надо добавить юридическое лицо - уже после внедрения на прод. Притом у юридического лица почти всё одинаковое, кроме некоторых полей. И параллельно выясняется, что запросы нужно делить по общей сумме: при малых суммах всё как сейчас, а при большых добавляется проверки в полиции и пр. И для этих проверок нужна дополнительная инфраструктура. Ввели второй этап. А на третьем этапе выясняется новая тема, которая вообще не планировалась, но она сильно нужна, потому что много даёт денег - запрсы в китай - а там вообще всё по другому. Как пректировать АПИ столь динамично развивающихся систем? Притом заранее известно, что система будет сильно менятся на проде, но не известно в какую сторону?
P.S. Это ситуация из реальной жизни.
Вы только что описали как работает 1с)
@@ГордиенкоДмитрий-ч6е 😂
@@ГордиенкоДмитрий-ч6е я вообще спрашиваю серьёзно. Есть клиент, который готов платить - это живые деньги, которые можно забрать себе - и у него горит, т.е. он готов тебе их отдать. И глупо их не взять. Поэтому нужно быстро разработать маленькую систему и пустить её в прод. Притом это крупный клиент, и он точно будет хотеть больше. И нужно сделать так, чтобы новая система могла расти дальше... в любую сторону. ЭТО РЕАЛЬНОСТЬ. и в ней приходиться жить, и проектировать...
Ну, тут либо смириться и не претендовать на звание "хороший" API, предупреждать всех, что рано или поздно начнутся проблемы. Либо, как мне кажется, просто все серьёзные апдейты должны быть в новой версии API, под которую пишется новая версия клиента. Да, если "нужно было вчера выкатить фичу", такое не прокатит, но тут не удастся и рыбку съесть и ..., ну вы понимаете.
Как вариант - думать наперёд и задавать правильные вопросы заказчику ))
Хм, так вроде SHOW это как раз-таки по стандарту работы с ресурсом, разве нет? (GET, POST, GET (show by id), PUT, DELETE)
Это слово путает разработчиков. С get все ясно и понятно. А что такое show?. Можно отправить post rpc запрос show on server my local logs. Или ещё что-то. По сути это не гет запрос, а пост запрос на вызов процедуры где-то там. А в другой директории может быть другой show но уже get. Типа showUserById. И как потом в этом зоопарке разобраться? Вот что имел ввиду соер.
мне кажется с названиями самое сложное.. особенно если в приложение много файлов и папок, и английский не очень.. сначала в одной папке поработал, через неделю в другой, а в третей уже все по новой придумываешь, потому что забыл первоначальные названия, не знаю может это с опытом приходит...
Я поработал какое время в русскоязычной команде, какое то время в польской и сделал такой вывод: хоть английский поначалу и сложнее для восприятия, это единственное верное решение для наименования. Всё остальное это кринж, бегите оттуда))
Хорошо бы разбор апи , есп32 прожектов разбор!
там json гоняют так же как на обычных проектах
есть конечно те, кто генерит хтмл, но это только потому, что он не в курсе построения приложений на современных вебтехнологиях
@@kalobyte это просто для тех хто знает... Тем и так всё понятно!
Не любил ни когда преподавателей которым и так всё понятно... Одной рукой пишет, другой стирает... Зачем что-то объяснять!
У меня уровень базиса С и Срр стм32cmsis ... Щас смотрю индуса и британца... стал чучуть понимать ВСкод....и то что прощеVS чемЕклипс(,експресиф)!
Про то как доставать поля из jsonпакетов... Перехватывать их ПостМен.... и тестировать!
Приходится смотреть 4 канала ... 2 по железу... 2 по вёрстке...и догадывался где с чем пересекается!
@@serggorod1423
🤣 можеш посмотреть, на какие каналы я подписан и что мне приходится смотреть
ты еще не смотрел ролики по реакту
но если ты пишеш под стм32 и на фреймворке производителя, то осилить веб будет намного проще
ты можеш сначала написать свой рестапи на есп и тестировать его постманом
в вскоде есть плагин для тестирования рестапи
а потом можеш отдельно писать вебморду и тестировать на компутере ее, а бекенд будет уже работать на есп
как только все заработает нормально, то можеш всю вебморду запаковать и залить в есп как обычно делается
есть готовые фреймворки, где за тебя уже кучу всего сделали и надо только все компоненты собрать в кучу и минифицировать при помощи вебпака или галпа
можеш посмотреть например такую штуку как lte admin
@@kalobyte спасибо посмотрю плагин в Вс.
Звучит ка план! Но всегда легче идти по чужим следам.
Люблю все функции писать / понимать сам без фреймов... Понимать все что написано...требует "очень много времени исследовать каждый пядь земли.... Кто бы прошёл показал сад, кто знает"
@@serggorod1423
фреймворк дает тебе возможность не изобретать велик, а пользоваться готовым, что сделали умные дядьки за много лет
я сейчас изучаю фреймворк один на пхп популярный и мне нравится это
там столько всякого есть, что облегчает тебе создание твоего приложения без заморочек на всякие мелочи
в вебе и десктопах никто ничего с нуля давно не пишет и юзают фреймворки, иначе программирование становится слишком сложным и унылым и тебе кажется, что все это никогда не осилить
Каналы про программирование они как каналы про качалку, зайди через 5 лет, а там один фиг основы ооп, рест апи 😂. Соер, тут один фиг 5 лямов просмотров не будет, давай уже про шардинг микросервисов, CDC, сравнение native у популярных фронтенд фреймворков.
Фронтендеров с их js недофреймворками на ютубе как 💩 на свалке. А Соер интересно и наглядно все рассказывает. Это архитектурные основы которых тут как раз мало, потому что они не хайповые, как например несчастные хуки в реакте, или супер пупер "новые" технологии по загаживанию фронтенда джаваскриптом.
@@artursveshnikov7668 это основы изучаются на втором уроке любых недокурсов и гуглятся на раз два, а набитые шишки в выборе нейтив фреймворка за 100 500 исследований человеко-часов соера и его команды избавят от кучи гемора и набивания шишек. В идеале узнать инфы за которую работодатель соера выложил сотню другую тысяч баксов ))
@@interstellarv0id эти основы если где и изучаются, то очень поверхностно. Я к тому, что на Ютубе мало кто эту тему вообще затрагивает. А фронтенд Фреймворками он завален на любой вкус.
соер не рассказывает про основы рест апи, а анализирует описания реальных апи в компаниях
Почему в JavaScript (0.1+0.2) == 0.3 false?
Проблема представления дробных чисел в памяти. Если выведешь в консоль сумму 0.1+0.2 увидишь что-то типа 0.2999999999998 или 3.000000000001 что не эквивалентно значению 0.3
Дробные числа сравнивать оператором == в принципе является дурным тоном. Более правильный подход проверять находится ли разница двух значений в пределах допустимой погрешности
Например вместо
0.1+0.2 ==0.3
правильнее написать
abs(0.1+0.2-0.3) < 0.00001
Не уверен что в js есть abs, я если что имел ввиду модуль. Находится ли разница между числами 0.1+0.2 и 0.3 в пределах 0.000001, если находится то мы считаем что эта разница равна нулю, иначе - отлична от нуля
0.30000000000000004.ком если желаешь узнать, что не в JS дело (само собой нужно догадаться заменить ком на com)
IEEE754 стандарт можно почитать
+
"дэлет" читается "делит".
Очень тихо
Я работаю в компании, которая занимается интеграцией своих программных продуктов в ERP заказчиков с учётом пожеланий, из-за этого все api разрабатываются быстро и не хватает времени на то, чтобы хорошо их продумать, да и заказчики постоянно вносят изменения в протокол 🥲
Нужно ли создавать Swagger когда есть полная документация с примерами в Postman?
В название видео слово "команд" может выглядеть двусмысленным
Посоветуйте, пожалуйста, курсы по продуктовой аналитике
Про какие можно почитать ?
Буду очень благодарен!
просто с ходу лайк от СЕООНЛИ
как всегда - про
Монтаж жесть конечно, смотреть максимально трудно
Почему бы не показывать код на весь экран и не дёргать его туда-сюда?
5:44 это что?
Смотреть некогда, но лайк ,комент , и до встречи в будущем... Апи НУЖНО! СПС!