Архитектура и принципы REST. Что значит RESTful? Что такое SOAP? Какие проблемы решает GraphQL?
ฝัง
- เผยแพร่เมื่อ 9 ก.ค. 2024
- Привет, это видео - одна из частей моих лекций в рамках проекта "ITMO.Mentors". Рассказываю про архитектуру REST, принципы REST, о том, что было до появления REST (SOAP) и о том, что должно быть после него (GraphQL).
Полезные ссылки:
Презентация и аннотация - t.me/davidobryakov/1001
Телеграм-канал - t.me/davidobryakov
Написать мне - t.me/kantegory
Ставить звёздочки на гитхабе - github.com/kantegory
VDS со скидкой в 10% - vdsina.ru/?partner=uxkhnzk56y
Таймкоды:
00:00 Вступление
00:05 Клиент-серверное взаимодействие (http)
01:17 Что такое REST?
01:40 Принципы REST
10:35 HTTP-методы
12:01 Статус-коды HTTP
15:01 Что было до REST? (SOAP)
21:14 Что было дальше? (GraphQL)
31:57 Заключение (+анонсы)
Учился с этим челиком в школе, красава
Лучшее видео, что я нашел по этой теме, все понятно и лаконично. Спасибо)👍
Очень понятно и структурировано, огромное спасибо!
отличный канал! автору спасибо!)
Все классно понятно! Благодарю за объяснение
Очень понятно , огромное спасибо!
Супер! Благодарю!
Большое спасибо за видео! Помогло понять суть
Очень классное видео, спасибо!)
очень неточный пересказ документации
Отличное видео, все на понятном языке, спасибо.
вор аватарок
Очень информативное видео! Спасибо автору, здоровья и больше подписчиков!
Очень классный ролик, спасибо!
КРАСАВЧИК ^_^😊
Отличное видео, спасибо огромное!
Спасибо, очень информативно!
доступно і цікаво, дякую! лайк + підписка!
супер!
respect bro, it was very cool, thanks
22:40 в чем проблема сделать АПИ №3 которое будет возвращать все нужные данные? не вижу сдесь проблемы........
JSON это XML совместимый формат, можно парсить туда и обратно, нужны только договоренности как назвать вложенные объекты например "children". Мне не приходит в голову кейс, где у XML больше возможностей. Может вы знаете такой? Строкой покрываются любые не стандартные типы данных.
Спасибо)
Спасибо.
Правильно ли я понимаю, что приложение не может обойтись только GraphQL endpoint'ами? Например, когда мы производим перевод денег в банковском приложении, то по нажатию на кнопку "Отправить" в REST приложении уходит запрос /transaction/send и происходит куча каких-то операций. Как в таком случае должен выглядеть запрос на GraphQL? Будет создан кастомный тип transaction и будет отправляться POST запрос на якобы создание сущности transaction?
Ну то есть сложилось впечатление, что GraphQL отлично подходит для CRUD-овских endpoint'ов. А если что-то посложнее, то как?)
Да, одного GraphQL недостаточно
Коммент в поддержку канала! Удачи!
GraphQL классная штука, на нем очень удобно реализовывать комплексные мутации, например, удалить один товар из корзины и тут же в одном запросе добавить новый. И сразу в схеме можно описывать какие поля в запросе кешируются, а какие нет
Мне бы очень хотелось поработать с ним где-нибудь в рамках реального проекта, но пока, к сожалению, не удалось.
Держи лайк. Спасибо за видео! Хотя в конце 5 минут извинений можно было бы заменить на объяснение откуда взялся класс Book. Он подсвечивается как класс, но на скриншоты декларация не вошла. Неполнота картины - это главная проблема у начинающих.
Поддерживаю!
А как у GraphQl с кэшированием? Там же вроде запросы хитровывернутые. Как кешировать ответы?
Нет кеша с коробки, нужно использовать дополнительный софт
спасибо автору
Огонь
Чем put отличается от patch?
put заменяет ВСЕ поля объекта, а patch может изменить только одно поле. Put по сути заменяет всё кроме айдишника получается. По опыту, чаще используется patch, потому что всё менять тебе не нужно так часто.
@@inmosh большое спасибо.
Не совсем понял, почему вы называете REST архитектурой. Это больше похоже на стиль взаимодействия компонентов, в крайнем случае это можно назвать узкоспециализированным архитектурным паттерном. Мы же не называем, например, очередь сообщений архитектурой.
что у тебя пищит?
"XML в далёком прошлом"
Разработчики из банковского сектора, где xml только ввели как золотой стандарт, хватаются за сердце.
Банковский сектор - это отдельный мир, но указание ценное. Спасибо! Я и сам заметил, что множество платёжных систем до сих пор через XML общаются. Но там, к счастью, не SOAP и это уже хорошо :)
Спасибо! Если перейдёте с рунглиш на русский будет отлично.
Это так не работает
@@snap-313 А Вы пробовали?
Проф. деформация на фоне рабочих чатиков) Пытаюсь что-то с этим сделать, но пока не очень хорошо выходит
@@dobryakov Признание существования проблемы - это, я считаю, первый большой шаг на пути к её решению. И уже успех. Потому что большинство и его не сделало.
Дорогу осилит идущий. От души желаю окончательного успеха!
Здорово, спасибо!
REST гут, но, SOAP в 100500 раз удобнее для межсерверного взаимодействия.
Ну, и судя потому, что не упомянул такую штуку как WSDL, видимо SOAP сервисы и клиенты всё же не писал.
Парсинг и формирование XML-сообщений вообще за рамками продуктивного кода, от слова совсем :)
Тупо работаешь с удалённым сервисом как с объектом в своем коде, что может быть проще или быстрее с точки зрения разработчика?
Уж точно не REST )
1. Супер
2. Ты ничего не должен и не обязан
3. Тратить время на учёбу вместо развития себя, как специалиста... - проблема века
про GraphQL автор просто прочитал шапку доки, ничего по сути не сказал
ролик можно было сократить в 2 раза, если не лить воду.
боже
что за бред
рест это архитектурный стиль, а soap это протокол взаимодействия
как же бесят особенно когда в вакансии рест ставят на один уровень с soap
Чел он об этом и говорит в видео. Держи в руках свою токсичность 25:04
Что за бред несёт этот человек. Граф кл нагружает базу данных?
Да потому что запросы ебические получается с использованием графкуэль
Ходил с ним в детский сад,крутой чел
Graphql не понятно братик