Боже, шикарно. Не знаю, на счет милд-разрабов, но для среднестатистического аналитика все более чем понятно. Повествование идеальное, очень легко воспринимается и смотрится.
1:06:00 - Я не против SOAP он хорош за счет стандартов, но не совсем корректно про документацию REST. Там можно сваггер использовать, который будет сам генерить JSON документацию для REST. 0 человеческого фактора, все генериться налету.
Отличное видео, многое понятнее стало. Примеры где что использовать хорошие. Таймкоды было бы полезно добавить в таком длинном видео. Закладки приходится добавлять где остановился.
Совет джунам - слушайте тех и учитесь только у тех, кто пишет код. Автор норм рассказал про соап, т.к. похоже работал много с ним когда-то. Но про современные практики в rest, graphql и пр. уже видно, что только по верхам знает. Поэтому ошибочно критикует их
@@SergeyNemchinskiy Правильный ответ на Задание 5: ruclips.net/video/P2wA_JehjK8/видео.html - Использовать службу DEA = Drug Enforcement Administration ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%BE_%D0%B1%D0%BE%D1%80%D1%8C%D0%B1%D0%B5_%D1%81_%D0%BD%D0%B0%D1%80%D0%BA%D0%BE%D1%82%D0%B8%D0%BA%D0%B0%D0%BC%D0%B8
1:23:51 -- надо было ограничиться ответом "нет, опыта с GraphQL нет". )) На сервере замечательно контролируется, кому, сколько и каких данных отдавать, и уж тем более, какие мутации делать. А тотально открытом CRUD речь не идет.
32:50 а вот тут не согласен, в питоне всё тоже из коробки есть. Пишешь сериализаторы, привязывашь их к модели, втыкаешь пару дженериков и за час сервис готов.
56:49, come on, зачем спорить о том, что уже давно решено: JSON лаконичнее, чем XML. Для того, чтобы сравнить с примерами: gist.github.com/DScheglov/86a54539259f9bf4a615fa29e85b46e1 Ну и самое главное, как раз для случаев с адресами подходят кортежи, которые поддерживаются json-schema: json-schema.org/understanding-json-schema/reference/array.html#tuple-validation Тогда пример с "лицом" будет выглядит вот так: gist.github.com/DScheglov/97637b77a7a6f79e9791c32715a11bd0
10:22 не даю соврать: реально все так. Дублирование полей, нихрена никто не знает часто что, зачем и почему одно и то же несколько раз по разному используется и т.д.
Его давно используют как транспорт. А для SOAP исторически так используют, хотя транспортом для SOAP теоретически даже файлы могут быть. Спасибо администраторам, которые готовы открывать только 80 и 443 порты. HTTP превратился в транспорт. И дело не в моделях OSI , а в практическом использовании и его роли в обменах между системами. Терминология OSI - это не всегда терминология механизмов обмена.
Brennende Herz лол, это каким же магическим образом http прыгнул на уровень ниже в OSI и «превратился» в транспорт? HTTP - это просто соглашение по формату текстовых сообщений, которые передаются по TCP. Он не был и не будет транспортом.
@@OverEngineer Вы невнимательно прочитали сообщение и пишете про OSI. В сообщении написано не про терминологию OSI где HTTP был и остается прикладным. Было написано про фактическую ситуацию, когда его стали использовать в механизмах обмена как транспорт для совершенно неприкладных данных. Его используют для передачи SOAP пакетов - именно передачи, а не прикладного использования. В него теперь пихают Base64 передавая файлы и PDF - только чтобы передать файлы и PDF. Никакой цели прикладного использования HTTP при этом не стоит. Прикладным это использование является для специалиста по CISСO или администратора сетей. На практике - это чистой воды "возьми здесь из базы данных - перевези в другую базу данных".
Наша песня хороша - начинай сначала ))) Администраторы и безопасники в компаниях сделали доступным для широкого использования только порты 80 и 443. Поэтому изначально прикладной протокол принял на себя в том числе исключительно транспортную роль.
Терминология OSI остается для сетевиков. А когда речь заходит об обмене данными можно учлышать вопрос "Какой транспорт будем использовать? Обычный HTTP? Или TCP соединения можно сразу писать?" "Да ну нафиг , TCP безопасники зарубят, давай сразу транспортом HTTP выберем".
Цепляться к терминологии OSI здесь бесполезно - это другой уровень терминологии и абстракции. И HTTP с этой точки зрения давно можно сравнивать с любыми другими траспортами. Но если хочется - то можно говорить что HTTP - прикладной протокол. И вот так мы по прикладному бинарные данные кидаем туда сюда и SOAP пакеты с JSON-ами, которые используются только для общения программ друг с другом.
Brennende Herz HTTP всегда использовался для протоколов более высокого уровня, это не делает его транспортным. Опять же - это просто соглашение по формату сообщений. Пускай будет «http-транспорт» если кому-то так удобно, но вообще ни при каких условиях нельзя сравнивать TCP/UDP и HTTP. HTTP реализуется прикладным ПО, а TCP системным, и первое без второго не существует. что значит «давай использовать http, tcp безопасники зарубят», когда http использует tcp? Тут речь идет лишь об открытых/закрытых портах, только и всего, а слушать 80/443 порты может что угодно, а не только http сервер. 80/443 - это всего лишь соглашение.
@@OverEngineer Ок. Речь была именно о транспорте, а не "протоколе транспортного уровня модели OSI". И в видео не было сказано про OSI ничего. Говорилось о транспортном протоколе именно в смысле "транспорта". А сравнение с UDP было в контексте надежности передачи. UPD не надежен по доставке , а REST не надежен по валидации. И за пределами Java Script REST , построенный на JSON-ах действительно крайне ненадежен. Заходишь на сайт , json-schema. org , а там вечная надпись "NEW DRAFT" висит. Да и про схему для JSON мало кто из разработчиков слышал, кто ресты делает на право и налево. Что касается транспорта, честно говоря не знаю ни одного прикладного программиста, кто бы в обычном общении с коллегами соблюдал бы терминологический пуризм и избегал говорить "используем HTTP как транспорт" только потому что в модели OSI это слово уже занято под один из лееров. >> ни при каких условиях нельзя сравнивать TCP/UDP и HTTP Передавая бинарные данные или текстовые даныне в бинарном виде очень даже можно сравнивать. Даже можно расписать плюсы и минусы каждого "транспорта". Поддержку во фреймворках. Отношение администраторов. А чего не сравнить то? Почему нельзя? OSI запрещает? ;)) "Нельзя ни при каких условиях" - это слишком громко сказано. Максимализм какой-то )) >> HTTP всегда использовался для протоколов более высокого уровня Не всегда. Далеко не всегда. Особенно если употреблять прошедшее время. Достаточно прочитать историю его возникновения и изначальное применение. Изначально это был протокол доступа к текстовым документам в Интернете для формирования страничек в браузере. Назначением и целью был текст. Тогда ни про SOAP ни про SJON не думал даже никто. Теперь текст - не цель, а средство транспортировки пакетов, которые в идеале было бы проще даже не текстом передавать, так как машинам именно текст не нужен.
Есть нечто похожее на GraphQL, но прошедшее стандартизацию в OASIS. Называется OData. Применяется почти исключительно в MS и SAP. Как-то не пошло в массы, хотя идеи там хорошие.
@@ram9914-k1u имеется в виду что REST не на HTTP никто не видел никогда, по крайней мере очень интересно было бы посмотреть, сможете навести примеры? А если придираться к словам Сергея, то да, конечно, сформулировано было не совсем корректно, учитывая то абстрактное описание которое давал Рой.
@@Skalpelgimbarr я к тому что упоминание HTTP лишнее, оно к rest отношения никакого не имеет. Это может спутать людей. Филдинг вроде принимал участие в стандартизации HTTP, возможно это повлияло на то что они так подходят. Я примеров реальных не знаю. Например есть SPDY, QUIC протоколы как альтернатива HTTP. Есть также WEbSocket. Также бывает невозможно точно найти соответствие корректному методу HTTP для запроса, и что теперь это не REST? может показаться. Не более того.
Всё верно, поверх HTTP это просто частая реализация, а так хоть голубями пересылать можно. Более того, то о чем Сергей рассказывает это никакой не REST, а web API просто. Я не знаю почему он так рассказывает, может хочет быть ближе к жизни, где программисты, не знающие теории - "мы используем POST, а значит это REST".
This integration is going to hell... You promised me JSON then sent XML You say it works in a RESTful way Then your errors come back as 200 OK Вспомнилась забавная песенка про REST: ruclips.net/video/nSKp2StlS6s/видео.html
wadl аналог wsdl для REST, хоча в живу його ніколи не бачив)) а так swagger aml - трохи більше часу на розробку, але це вже повноцінна і більш читаєма документація, на відміну від wsdl, відповідно можна показати клієнту, а не тільки девам. А на рахунок валідації це да, але якщо публічне АРІ зміниться то клієнти точно не будуть раді і не важливо як вони інтегровані)))
Меня "зовут" - это пассивный залог. Позиция жертвы чаще свойственна тем, кто использует пассивный залог в речи. Напротив того, активный залог в речи способствует поддержанию позиции Автора. www.psychologos.ru/articles/view/chasche-ispolzuyte-aktivnyyzpt-a-ne-passivnyy-zalog-v-rechi
Анекдот про REST : Кабина самолета. Тишина. Пилот штурману:
- Штурман, приборы!
- Двести.
Летят дальше.
- Что "двести"?!
- А что "приборы"?
Боже, шикарно. Не знаю, на счет милд-разрабов, но для среднестатистического аналитика все более чем понятно. Повествование идеальное, очень легко воспринимается и смотрится.
1:06:00 - Я не против SOAP он хорош за счет стандартов, но не совсем корректно про документацию REST. Там можно сваггер использовать, который будет сам генерить JSON документацию для REST. 0 человеческого фактора, все генериться налету.
Openapi
Redoc
Причём все эти сервисы копипастом подключаются за минуту
Отличное видео, многое понятнее стало. Примеры где что использовать хорошие. Таймкоды было бы полезно добавить в таком длинном видео. Закладки приходится добавлять где остановился.
добавили :)
Сергей спрашивает:
- на чем лучше это сделать, на REST или SOAP?
ответ в чате:
- на javascript
я проорал 😂
Совет джунам - слушайте тех и учитесь только у тех, кто пишет код. Автор норм рассказал про соап, т.к. похоже работал много с ним когда-то. Но про современные практики в rest, graphql и пр. уже видно, что только по верхам знает. Поэтому ошибочно критикует их
Спасибо, нормально, по человечески объяснил.
всегда стараюсь объяснять именно так)
@@SergeyNemchinskiy
Правильный ответ на Задание 5:
ruclips.net/video/P2wA_JehjK8/видео.html
- Использовать службу DEA = Drug Enforcement Administration
ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D0%BE_%D0%B1%D0%BE%D1%80%D1%8C%D0%B1%D0%B5_%D1%81_%D0%BD%D0%B0%D1%80%D0%BA%D0%BE%D1%82%D0%B8%D0%BA%D0%B0%D0%BC%D0%B8
😉так весело , смотрела как стендап 😂
Спасибо, у вас отличные лекции.
1:23:51 -- надо было ограничиться ответом "нет, опыта с GraphQL нет". ))
На сервере замечательно контролируется, кому, сколько и каких данных отдавать, и уж тем более, какие мутации делать. А тотально открытом CRUD речь не идет.
32:50 а вот тут не согласен, в питоне всё тоже из коробки есть. Пишешь сериализаторы, привязывашь их к модели, втыкаешь пару дженериков и за час сервис готов.
возможно в жабе проблемы с рест фреймворками.. хотя, нет не верю. а так, согласен, drf наше все )
Ты про джанго наверное
@@mmospanenko drf - django-rest-framework
56:49, come on, зачем спорить о том, что уже давно решено: JSON лаконичнее, чем XML.
Для того, чтобы сравнить с примерами: gist.github.com/DScheglov/86a54539259f9bf4a615fa29e85b46e1
Ну и самое главное, как раз для случаев с адресами подходят кортежи, которые поддерживаются json-schema:
json-schema.org/understanding-json-schema/reference/array.html#tuple-validation
Тогда пример с "лицом" будет выглядит вот так:
gist.github.com/DScheglov/97637b77a7a6f79e9791c32715a11bd0
JEE, SOAP, WSDL
ah shit here we go again
1:24:30 - @Sergey Nemchinskiy -- "GraphQL из говна и палок" -- это примерно тоже самое, что "ненавижу XML".
@Sergey Nemchinkiy почему нет таймкодов, хотя бы где начало доклада, и откуда начинаютьсч вопросы
некому сделать. сделаете?
@@TetyanaAlymova ага, смешно
@@ME-ls9de вот и мне смешно
О, эти дискуссии о http-методах. Сколько волос и зубов было вырвано!
Выглянул в окошко , смотрю 2020 год .. но смотрю тут про XML ..
уже и yaml json вытесняет потихоньку)
Бекенджщики в Постмене описывают методы запроса,модели, какие парамсы необходимы и тд. И ни каких проблем с REST.
10:22 не даю соврать: реально все так. Дублирование полей, нихрена никто не знает часто что, зачем и почему одно и то же несколько раз по разному используется и т.д.
HTTP не транспортный протокол. Его нельзя сравнивать с UDP, так как они находятся на разных уровнях модели OSI
Его давно используют как транспорт. А для SOAP исторически так используют, хотя транспортом для SOAP теоретически даже файлы могут быть. Спасибо администраторам, которые готовы открывать только 80 и 443 порты. HTTP превратился в транспорт. И дело не в моделях OSI , а в практическом использовании и его роли в обменах между системами. Терминология OSI - это не всегда терминология механизмов обмена.
Brennende Herz лол, это каким же магическим образом http прыгнул на уровень ниже в OSI и «превратился» в транспорт? HTTP - это просто соглашение по формату текстовых сообщений, которые передаются по TCP. Он не был и не будет транспортом.
@@OverEngineer Вы невнимательно прочитали сообщение и пишете про OSI. В сообщении написано не про терминологию OSI где HTTP был и остается прикладным. Было написано про фактическую ситуацию, когда его стали использовать в механизмах обмена как транспорт для совершенно неприкладных данных. Его используют для передачи SOAP пакетов - именно передачи, а не прикладного использования. В него теперь пихают Base64 передавая файлы и PDF - только чтобы передать файлы и PDF. Никакой цели прикладного использования HTTP при этом не стоит.
Прикладным это использование является для специалиста по CISСO или администратора сетей. На практике - это чистой воды "возьми здесь из базы данных - перевези в другую базу данных".
Наша песня хороша - начинай сначала ))) Администраторы и безопасники в компаниях сделали доступным для широкого использования только порты 80 и 443. Поэтому изначально прикладной протокол принял на себя в том числе исключительно транспортную роль.
Терминология OSI остается для сетевиков. А когда речь заходит об обмене данными можно учлышать вопрос "Какой транспорт будем использовать? Обычный HTTP? Или TCP соединения можно сразу писать?" "Да ну нафиг , TCP безопасники зарубят, давай сразу транспортом HTTP выберем".
Цепляться к терминологии OSI здесь бесполезно - это другой уровень терминологии и абстракции. И HTTP с этой точки зрения давно можно сравнивать с любыми другими траспортами.
Но если хочется - то можно говорить что HTTP - прикладной протокол. И вот так мы по прикладному бинарные данные кидаем туда сюда и SOAP пакеты с JSON-ами, которые используются только для общения программ друг с другом.
Brennende Herz HTTP всегда использовался для протоколов более высокого уровня, это не делает его транспортным. Опять же - это просто соглашение по формату сообщений. Пускай будет «http-транспорт» если кому-то так удобно, но вообще ни при каких условиях нельзя сравнивать TCP/UDP и HTTP. HTTP реализуется прикладным ПО, а TCP системным, и первое без второго не существует. что значит «давай использовать http, tcp безопасники зарубят», когда http использует tcp? Тут речь идет лишь об открытых/закрытых портах, только и всего, а слушать 80/443 порты может что угодно, а не только http сервер. 80/443 - это всего лишь соглашение.
@@OverEngineer Ок. Речь была именно о транспорте, а не "протоколе транспортного уровня модели OSI". И в видео не было сказано про OSI ничего. Говорилось о транспортном протоколе именно в смысле "транспорта". А сравнение с UDP было в контексте надежности передачи. UPD не надежен по доставке , а REST не надежен по валидации. И за пределами Java Script REST , построенный на JSON-ах действительно крайне ненадежен. Заходишь на сайт , json-schema. org , а там вечная надпись "NEW DRAFT" висит. Да и про схему для JSON мало кто из разработчиков слышал, кто ресты делает на право и налево.
Что касается транспорта, честно говоря не знаю ни одного прикладного программиста, кто бы в обычном общении с коллегами соблюдал бы терминологический пуризм и избегал говорить "используем HTTP как транспорт" только потому что в модели OSI это слово уже занято под один из лееров.
>> ни при каких условиях нельзя сравнивать TCP/UDP и HTTP
Передавая бинарные данные или текстовые даныне в бинарном виде очень даже можно сравнивать. Даже можно расписать плюсы и минусы каждого "транспорта". Поддержку во фреймворках. Отношение администраторов. А чего не сравнить то? Почему нельзя? OSI запрещает? ;))
"Нельзя ни при каких условиях" - это слишком громко сказано. Максимализм какой-то ))
>> HTTP всегда использовался для протоколов более высокого уровня
Не всегда. Далеко не всегда. Особенно если употреблять прошедшее время. Достаточно прочитать историю его возникновения и изначальное применение. Изначально это был протокол доступа к текстовым документам в Интернете для формирования страничек в браузере. Назначением и целью был текст. Тогда ни про SOAP ни про SJON не думал даже никто. Теперь текст - не цель, а средство транспортировки пакетов, которые в идеале было бы проще даже не текстом передавать, так как машинам именно текст не нужен.
По опыту интеграций, только старые поставщики используют соап, все современные интеграции были на ресте
Сергей тоже не молодой уже)
Есть нечто похожее на GraphQL, но прошедшее стандартизацию в OASIS. Называется OData. Применяется почти исключительно в MS и SAP. Как-то не пошло в массы, хотя идеи там хорошие.
Отличное видео
Так, ну к середине ролика я уже понял, что Рест - это костыли мирового масштаба.
Отличные обзорные лекции. Не смог не задонатить
правильно, не сдерживайтесь))) спасибо)
да по этим видео можно научиться программировать, и на работу устроиться.
спасибо. жаль мне б это видео пораньше найти
что скажите про gRPC?
потом горе-кодеры будут пытаться натянуть сову на глобус, т.е. транзакции на соап.
Ууух, щас бы объяснять отличия rest между soap сервисами 2 часа
Интересно как была реализована система бронирования жд билетов с помощью эвм в ссср
Сергей, это Вы?
Здравствуйте, Cергей! Проверьте пожалуйста почту c предложением от ConveyThis.
добрый день! на какую именно почту вы писали?
@@TetyanaAlymova events@foxminded.com.ua на эту
@@davepetrov2216 странно, ничего нет. продублируйте, пожалуйста.
@@TetyanaAlymova ok
Обоже, это еще с тех древних времен когда я пхп руками трогал... Где же вы откопали такие слова)))
Rest in peace
Разве REST требует использования HTTP? В диссертации Роя Филдинга об этом ни слова, также как и ни слова про методы HTTP.
оно то так, но Вы видели когда то REST не на HTTP?
@@Skalpelgimbarr а вы видели когда нибудь машину без колес? Нет. А чтобы соблюдать ПДД колеса имеют значение? Тоже нет.
@@ram9914-k1u имеется в виду что REST не на HTTP никто не видел никогда, по крайней мере очень интересно было бы посмотреть, сможете навести примеры? А если придираться к словам Сергея, то да, конечно, сформулировано было не совсем корректно, учитывая то абстрактное описание которое давал Рой.
@@Skalpelgimbarr я к тому что упоминание HTTP лишнее, оно к rest отношения никакого не имеет. Это может спутать людей. Филдинг вроде принимал участие в стандартизации HTTP, возможно это повлияло на то что они так подходят. Я примеров реальных не знаю. Например есть SPDY, QUIC протоколы как альтернатива HTTP. Есть также WEbSocket. Также бывает невозможно точно найти соответствие корректному методу HTTP для запроса, и что теперь это не REST? может показаться. Не более того.
Всё верно, поверх HTTP это просто частая реализация, а так хоть голубями пересылать можно. Более того, то о чем Сергей рассказывает это никакой не REST, а web API просто. Я не знаю почему он так рассказывает, может хочет быть ближе к жизни, где программисты, не знающие теории - "мы используем POST, а значит это REST".
Soap и xml/xsd это прошлый век. Rest и Json сериализация решает. Плюс кафка с тем же json
Я бы тебе не серебряную , а золотую бы кнопку дал.
хорошо бы и поскорей бы)))
This integration is going to hell...
You promised me JSON then sent XML
You say it works in a RESTful way
Then your errors come back as 200 OK
Вспомнилась забавная песенка про REST:
ruclips.net/video/nSKp2StlS6s/видео.html
wadl аналог wsdl для REST, хоча в живу його ніколи не бачив)) а так swagger
aml - трохи більше часу на розробку, але це вже повноцінна і більш читаєма документація, на відміну від wsdl, відповідно можна показати клієнту, а не тільки девам. А на рахунок валідації це да, але якщо публічне АРІ зміниться то клієнти точно не будуть раді і не важливо як вони інтегровані)))
Зп меньше тыщи долларов и использую SOAP
Надеюсь уже сменили место работы?)
купи микрофон дороже 200 рублей пожалуйста
Меня "зовут" - это пассивный залог. Позиция жертвы чаще свойственна тем, кто использует пассивный залог в речи. Напротив того, активный залог в речи способствует поддержанию позиции Автора. www.psychologos.ru/articles/view/chasche-ispolzuyte-aktivnyyzpt-a-ne-passivnyy-zalog-v-rechi