Разбираюсь в API крутых команд

No video

Разбираюсь в API крутых команд

Рет қаралды 27,278

Жыл бұрын

#soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwareengineervlog
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/id/5f578bdf22e2...
GitHub - github.com/soerdev
Чат для программистов - / discord
Группа ВК - codeartblog

Пікірлер: 66

@artursveshnikov7668 Жыл бұрын

Супер тема, надеюсь дальше будешь продолжать подобное. Это не какие-то библиотечки одногодки, это основа, которой на ютубе мало, потому что не хайповая.

@user-kw4kp7eq9m Жыл бұрын

Спасибо за очень хорошое объяснение!

@ruslanboroda5145 Жыл бұрын

Огромное спасибо за информацию!

@apdgslfhsodbna Жыл бұрын

Я работаю в компании, которая занимается интеграцией своих программных продуктов в ERP заказчиков с учётом пожеланий, из-за этого все api разрабатываются быстро и не хватает времени на то, чтобы хорошо их продумать, да и заказчики постоянно вносят изменения в протокол 🥲

@ArtiomKravchenko Жыл бұрын

Swagger надо, чтоб был источник актуальных данных. Ну и чтоб разработчики его исправно вели ) Ну или чтоб кто-то один отвечал за обновление коллекции Постман и ее расшаривал на общем ресурсе )

@ILICH1980 Жыл бұрын

посмотрел и понял что это не про построение а про то как сделано описание АПИ )))

@sergeyvas123 Жыл бұрын

Там вообще про АПИ ни слова, там про API.

@sovrinfo Жыл бұрын

Спасибо за видео. Коммент в поддержку!

@mtvspec 19 күн бұрын

На счет POST не соглашусь, а именно что можно использовать POST как признак, что тут создается ресурс, так как POST не всегда означает создание ресурса, POST может быть использован для получения ресурсов с передачей различных параметров в теле (body), которое в случае с GET не передается. Например, так POST /tasks/search { where: { name: { contains: "change bulb" } } } в этом случае POST может быть использован для получения списка задач, отфильтрованных по имени

@serggorod1423 Жыл бұрын

Смотреть некогда, но лайк ,комент , и до встречи в будущем... Апи НУЖНО! СПС!

@MrAnetto Жыл бұрын

По Salesforce не соглашусь. Соер говорит про неконсистентное API без примеров, что "это не страшный технический долг и продолжение от этого падать не будет". Таки будет, потому что клиентское приложение писать становится сложнее - нет примеров. Возможно, у них документация этот вопрос закрывает, но всё же иметь примеры ручек упрощает жизнь и уменьшает двусмысленность

@user-fx9nv1wu5q Жыл бұрын

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

@kl45gp Жыл бұрын

как всегда - про

@Das.Kleine.Krokodil 9 ай бұрын

Спасибо

@seoonlyRU Жыл бұрын

просто с ходу лайк от СЕООНЛИ

@tesority Жыл бұрын

кто мне объяснит, почему все делают частичное редактирование ресурса через PUT, а не PATCH? PUT - это замена (полностью) существующего ресурса другим (либо идемпотентное создание, если ресурс не существует), PATCH - частичное обновление. приведу пример: есть ресурс {id:1, name:Test}, мы хотим заменить имя на "NewTest". после PUT {name:NewTest}, ресурс будет равен: {name:NewTest}. после PATCH {name:NewTest}, ресурс равен: {id:1, name:NewTest}.

@qwiting Жыл бұрын

Тоже задавался данным вопросом

@sancocaparelli9732 Жыл бұрын

Введи в поиске "Why would you use PUT instead of PATCH?". Первым делом должна появиться страничка с StackOverFlow. Там описано. Если коротко - пользоваться PUT безопаснее, чем PATCH, потому что PUT идемпотентен, а PATCH - нет и может иметь сайд эффекты.

@tesority Жыл бұрын

нашел ответ в статье "Please. Don't Patch Like That.". метод PATCH в теле запроса несет не данные ресурса, а операции, которые нужно сделать с ресурсом для его обновления (пример есть в статье).

@katetometr Жыл бұрын

@@sancocaparelli9732 Как сделает бекендщик. так и будет, с-без сайдэффектов. Гугл. н-р, почти везде в своих апи юзает patch

@evilQuister Жыл бұрын

Он просто не вписывается в концепцию REST, использовать/не использовать - это на плечах архитектора, в зависимости от требуемых задач.

@mbalukh Жыл бұрын

все до 2х сотой являются положительным ответом и можно экономить ресурсы используя резервы от 200 до 299

@N5O1 8 ай бұрын

Нужно ли создавать Swagger когда есть полная документация с примерами в Postman?

@eugeneponomarov7429 Жыл бұрын

Хм, так вроде SHOW это как раз-таки по стандарту работы с ресурсом, разве нет? (GET, POST, GET (show by id), PUT, DELETE)

@artursveshnikov7668 Жыл бұрын

Это слово путает разработчиков. С get все ясно и понятно. А что такое show?. Можно отправить post rpc запрос show on server my local logs. Или ещё что-то. По сути это не гет запрос, а пост запрос на вызов процедуры где-то там. А в другой директории может быть другой show но уже get. Типа showUserById. И как потом в этом зоопарке разобраться? Вот что имел ввиду соер.

@pompei2 Жыл бұрын

А как проектировать АПИ, если заранее не известна структура? Например: вначале есть физическое лицо, продажа и запрос. Потом надо добавить юридическое лицо - уже после внедрения на прод. Притом у юридического лица почти всё одинаковое, кроме некоторых полей. И параллельно выясняется, что запросы нужно делить по общей сумме: при малых суммах всё как сейчас, а при большых добавляется проверки в полиции и пр. И для этих проверок нужна дополнительная инфраструктура. Ввели второй этап. А на третьем этапе выясняется новая тема, которая вообще не планировалась, но она сильно нужна, потому что много даёт денег - запрсы в китай - а там вообще всё по другому. Как пректировать АПИ столь динамично развивающихся систем? Притом заранее известно, что система будет сильно менятся на проде, но не известно в какую сторону? P.S. Это ситуация из реальной жизни.

@user-vq5vb7tz8v Жыл бұрын

Вы только что описали как работает 1с)

@pompei2 Жыл бұрын

@@user-vq5vb7tz8v 😂

@pompei2 Жыл бұрын

@@user-vq5vb7tz8v я вообще спрашиваю серьёзно. Есть клиент, который готов платить - это живые деньги, которые можно забрать себе - и у него горит, т.е. он готов тебе их отдать. И глупо их не взять. Поэтому нужно быстро разработать маленькую систему и пустить её в прод. Притом это крупный клиент, и он точно будет хотеть больше. И нужно сделать так, чтобы новая система могла расти дальше... в любую сторону. ЭТО РЕАЛЬНОСТЬ. и в ней приходиться жить, и проектировать...

@user-zt2ob3le7e Жыл бұрын

Ну, тут либо смириться и не претендовать на звание "хороший" API, предупреждать всех, что рано или поздно начнутся проблемы. Либо, как мне кажется, просто все серьёзные апдейты должны быть в новой версии API, под которую пишется новая версия клиента. Да, если "нужно было вчера выкатить фичу", такое не прокатит, но тут не удастся и рыбку съесть и ..., ну вы понимаете.

@indigoram89 Жыл бұрын

Как вариант - думать наперёд и задавать правильные вопросы заказчику ))

@serggorod1423 Жыл бұрын

Хорошо бы разбор апи , есп32 прожектов разбор!

@kalobyte Жыл бұрын

там json гоняют так же как на обычных проектах есть конечно те, кто генерит хтмл, но это только потому, что он не в курсе построения приложений на современных вебтехнологиях

@serggorod1423 Жыл бұрын

@@kalobyte это просто для тех хто знает... Тем и так всё понятно! Не любил ни когда преподавателей которым и так всё понятно... Одной рукой пишет, другой стирает... Зачем что-то объяснять! У меня уровень базиса С и Срр стм32cmsis ... Щас смотрю индуса и британца... стал чучуть понимать ВСкод....и то что прощеVS чемЕклипс(,експресиф)! Про то как доставать поля из jsonпакетов... Перехватывать их ПостМен.... и тестировать! Приходится смотреть 4 канала ... 2 по железу... 2 по вёрстке...и догадывался где с чем пересекается!

@kalobyte Жыл бұрын

@@serggorod1423 🤣 можеш посмотреть, на какие каналы я подписан и что мне приходится смотреть ты еще не смотрел ролики по реакту но если ты пишеш под стм32 и на фреймворке производителя, то осилить веб будет намного проще ты можеш сначала написать свой рестапи на есп и тестировать его постманом в вскоде есть плагин для тестирования рестапи а потом можеш отдельно писать вебморду и тестировать на компутере ее, а бекенд будет уже работать на есп как только все заработает нормально, то можеш всю вебморду запаковать и залить в есп как обычно делается есть готовые фреймворки, где за тебя уже кучу всего сделали и надо только все компоненты собрать в кучу и минифицировать при помощи вебпака или галпа можеш посмотреть например такую штуку как lte admin

@serggorod1423 Жыл бұрын

@@kalobyte спасибо посмотрю плагин в Вс. Звучит ка план! Но всегда легче идти по чужим следам. Люблю все функции писать / понимать сам без фреймов... Понимать все что написано...требует "очень много времени исследовать каждый пядь земли.... Кто бы прошёл показал сад, кто знает"

@kalobyte Жыл бұрын

@@serggorod1423 фреймворк дает тебе возможность не изобретать велик, а пользоваться готовым, что сделали умные дядьки за много лет я сейчас изучаю фреймворк один на пхп популярный и мне нравится это там столько всякого есть, что облегчает тебе создание твоего приложения без заморочек на всякие мелочи в вебе и десктопах никто ничего с нуля давно не пишет и юзают фреймворки, иначе программирование становится слишком сложным и унылым и тебе кажется, что все это никогда не осилить

@user-sv1ze9gk3b Жыл бұрын

@petrplotnikov4307 Жыл бұрын

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

@freedomtv2295 Жыл бұрын

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

@interstellarv0id Жыл бұрын

Каналы про программирование они как каналы про качалку, зайди через 5 лет, а там один фиг основы ооп, рест апи 😂. Соер, тут один фиг 5 лямов просмотров не будет, давай уже про шардинг микросервисов, CDC, сравнение native у популярных фронтенд фреймворков.

@artursveshnikov7668 Жыл бұрын

Фронтендеров с их js недофреймворками на ютубе как 💩 на свалке. А Соер интересно и наглядно все рассказывает. Это архитектурные основы которых тут как раз мало, потому что они не хайповые, как например несчастные хуки в реакте, или супер пупер "новые" технологии по загаживанию фронтенда джаваскриптом.

@interstellarv0id Жыл бұрын

@@artursveshnikov7668 это основы изучаются на втором уроке любых недокурсов и гуглятся на раз два, а набитые шишки в выборе нейтив фреймворка за 100 500 исследований человеко-часов соера и его команды избавят от кучи гемора и набивания шишек. В идеале узнать инфы за которую работодатель соера выложил сотню другую тысяч баксов ))

@artursveshnikov7668 Жыл бұрын

@@interstellarv0id эти основы если где и изучаются, то очень поверхностно. Я к тому, что на Ютубе мало кто эту тему вообще затрагивает. А фронтенд Фреймворками он завален на любой вкус.

@Das.Kleine.Krokodil 9 ай бұрын

соер не рассказывает про основы рест апи, а анализирует описания реальных апи в компаниях

@soltaurus Жыл бұрын

"дэлет" читается "делит".

@itforall89 Жыл бұрын

Почему в JavaScript (0.1+0.2) == 0.3 false?

@user-wr4rp3ht1u Жыл бұрын

Проблема представления дробных чисел в памяти. Если выведешь в консоль сумму 0.1+0.2 увидишь что-то типа 0.2999999999998 или 3.000000000001 что не эквивалентно значению 0.3

@user-wr4rp3ht1u Жыл бұрын

Дробные числа сравнивать оператором == в принципе является дурным тоном. Более правильный подход проверять находится ли разница двух значений в пределах допустимой погрешности Например вместо 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, если находится то мы считаем что эта разница равна нулю, иначе - отлична от нуля

@maxm1nd Жыл бұрын

0.30000000000000004.ком если желаешь узнать, что не в JS дело (само собой нужно догадаться заменить ком на com)

@apdgslfhsodbna Жыл бұрын

IEEE754 стандарт можно почитать