Один дядька в своей диссертации ввел новый термин, а все носятся с этим термином как с золотым яйцом. И да, это всего лишь рекомендации дядьки, которые он описал в своем диссере для обоснования этого нового термина. Можно ли назвать это архитектурным стилем? А почему нет? Модно, стильно, молодежно. Но это просто термин из чьей-то диссертации. Вот ты смотришь на API какой-то системы. Ты сразу понимаешь - это REST или что? Нет. Если API описано грамотно и подробно, то с ним легко работать всем остальным. А REST там или что - зачем это нужно знать для того, чтобы пользоваться API? И при проектировании системы/ПО ты будешь смотреть на входящие требования, а не в диссертацию какого-то дядьки. А второй дядька придумал модель зрелости по термину из чужого диссера. Молодчинка! Никаких стандартов, близких к уровню RFC или ISO standards про REST нет. Никаких сертификаций ИТ систем/ПО по REST нет. Никакое тестирование не проводится на соответствие REST. Никто не пишет о своей системе/ПО - реализовано в архитектурном стиле REST. И пока это просто вопрос на собеседовании. Не очень понятно, зачем. Не встречал, чтобы выйдя на проект, кто-то сказал: ребята, у вас тут не по REST, давайте все переделывать. Никто, возможно, просто из-за лени не стал придумывать новых или альтернативных терминов, а, может, и придумали, но эти термины не прижились или жили только во время защиты диссеров и/или статей.
Не очень понятно, почему при обсуждения кэширования говорится только о кэшировании на стороне сервера. Обычно при обсуждении REST говорят о кэшировании на стороне клиента или промежуточного узла. Ещё не очень прозрачен момент: не для всяких бизнес-данных кэширование возможно с точки зрения бизнес-смысла. Таким образом кэширование является скорее желательным, чем обязательным требованием.
Наш воркшоп по проектированию интеграции через REST API systems.education/rest-workshop
Это самое понятное и доступное объяснение, которое может быть! Больше таких спикеров - и It- специалистам станет легче жить) Благодарю
Прекрасная лекция! Лучшее объяснение REST, которое я встречала. Спасибо!
Наконец-то кто-то разложил всё по полочкам. Спасибо!
Очень рады, что Вам понравилось. Подписывайтесь на наш телеграм-канал t.me/systems_education
очень приятно, когда лектор знает и как есть, и как изначально планировал автор концепции. а еще и качественно и плотно доносит информацию. спасибо!
А вот и тренинг на эту тему
- Проектирование интеграции с REST API clck.ru/33dDJA
офигенно все объяснил огромное спасибо вам!!!
Отличный доклад/презентация. Систематизировали знания про rest, что очень полезно.
Спасибо за комметарий.
Большое спасибо! Очень круто
Автор живёт в 19 веке. Как ему в 21 веке получилось создать такую шикарную лекцию?
Видео отличное! Спасибо!))
Единственное - не рассказали что такое URI (идентификатор ресурса) но при этом он там мелькал где-то на 14 минуте.
Спасибо за Ваш отзыв!
Статья Андрея на основе материалов вебинара systems.education/what-is-rest
Один дядька в своей диссертации ввел новый термин, а все носятся с этим термином как с золотым яйцом.
И да, это всего лишь рекомендации дядьки, которые он описал в своем диссере для обоснования этого нового термина.
Можно ли назвать это архитектурным стилем? А почему нет?
Модно, стильно, молодежно. Но это просто термин из чьей-то диссертации.
Вот ты смотришь на API какой-то системы. Ты сразу понимаешь - это REST или что? Нет. Если API описано грамотно и подробно, то с ним легко работать всем остальным. А REST там или что - зачем это нужно знать для того, чтобы пользоваться API?
И при проектировании системы/ПО ты будешь смотреть на входящие требования, а не в диссертацию какого-то дядьки.
А второй дядька придумал модель зрелости по термину из чужого диссера. Молодчинка!
Никаких стандартов, близких к уровню RFC или ISO standards про REST нет.
Никаких сертификаций ИТ систем/ПО по REST нет.
Никакое тестирование не проводится на соответствие REST.
Никто не пишет о своей системе/ПО - реализовано в архитектурном стиле REST.
И пока это просто вопрос на собеседовании. Не очень понятно, зачем. Не встречал, чтобы выйдя на проект, кто-то сказал: ребята, у вас тут не по REST, давайте все переделывать.
Никто, возможно, просто из-за лени не стал придумывать новых или альтернативных терминов, а, может, и придумали, но эти термины не прижились или жили только во время защиты диссеров и/или статей.
8:20 Конверт - это протокол? Меня учили, что протокол это всегда про последовательность действий
Не очень понятно, почему при обсуждения кэширования говорится только о кэшировании на стороне сервера. Обычно при обсуждении REST говорят о кэшировании на стороне клиента или промежуточного узла. Ещё не очень прозрачен момент: не для всяких бизнес-данных кэширование возможно с точки зрения бизнес-смысла. Таким образом кэширование является скорее желательным, чем обязательным требованием.
Спасибо, комментарий по делу.
Сделали с Андреем Бураковым продолжение вебинара - ruclips.net/user/liverURUWnsBnDA
Спасибо за комментарий
В самом начале непонятно чем протокол отличается от транспорта, если транспорт - это протокол для передачи данных по определению лектора
Различие протокола и транспорта осталось непонятным
7:31 У русского слова "Синий" и у английского слова "Blue" вообще-то смысл разный.
на. русском значит пьяный
Сложно. Непонятно.
Приходите к нам на воркшоп, где все разбирается максимально наглядно
Проектирование интеграции с REST API
systems.education/rest-workshop