Сообщество GetAnalyst создано для объединения начинающих и опытных системных аналитиков, а также всех, кто хочет получить знания и опыт в проектировании программного обеспечения: от сбора требований до разработки архитектуры систем 🚀
Системный анализ | Бизнес-анализ | Проектирование и архитектура | Управление проектами | Практическое обучение
Добрый день! Так как во внешней системе он не был реализован и считаем, что детский лагерь может нам только предоставить API "как есть". С Callback конечно было бы красивее решение. Упоминала об этом в подкасте)) В этом плане вас может заинтересовать видео про вебхуки, если еще не видели: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-t4_1ov_pIOk.html
1. Никиту слышно плохо. 2. скорость речи разная - автора слушаю на 1,5х, а Никиту приходится обратно на 1х переключать - не удобно. 3. тема вроде бы исходя из названия видео мне (еще даже не джуну, просто учусь) примерно понятная (на вскидку - периодический get или ресурс для приема ответа), а тут ее растянули на 30+минут.
Очень интересный материал, спасибо! У меня возник вопросистый вопрос по части очереди на стороне страховой компании.. каким образом эти наши заявочки будут отправляться уже в саму мед организацию? (Вряд ли мед организация будет как консюмер выступать.. да и вряд у нас будет реализован пуш механизм для этих консьюмеров.. вот этот момент непонятен) Брокер как то сам будет эндпоинт медицинский вызывать?
Здравструйте! Спасибо за приятную обратную связь :) Отвечаю на вопрос. У нас есть два сценария. Мед.организация -> Страховая 1. Мед организация отправила запрос на обработку 2. Страховая поставила задачу в очередь к обработке заявок, она в ожидании автоматической или ручной обработки. Страховая -> Мед.организация 1. Заявку обработали. И теперь нам гарантированно надо доставить статус на мед. организацию. 2. Страховая кладет задачу на вызов внешней мед.системы в брокер. Задача находится в брокере, пока мед. система не ответит успехом, либо пока не выполнятся условия исключения задачи из брокера (21 день мед система реагирует ошибками и подобное) Верно поняла вопрос?
Насчет метода PATCH, что он идемпотентный можно поспорить. Он скорее частично идемпотентный или не является строго идемпотентным. К примреру, у нас есть объект "user" с полем "age". Вызов PATCH запроса с данными {"age": 30} увеличит возраст пользователя на 30 лет. Если повторно отправить точно такой же PATCH запрос с {"age": 30}, некоторые серверы могут интерпретировать его как повторное действие, увеличив возраст пользователя еще на 30 лет, а не оставив его неизменным. Таким образом, в данном случае результат не останется одинаковым, что противоречит строгой идемпотентности.
Добрый день! Пример скорее вырожденный. Похоже на то, что нужен какой-то counter (счетчик) на события именно под вашу задачу. И да, его можно сделать через PATCH :) На самом деле и под GET в REST API тоже можно заложить логику измениня данных в БД в процессе получения (например, увеличение счетчикаа на кол-во просмотров). И получается, что все методы частично идемпотентны. Можно начинать рассуждения о том, когда у нас просто REST API, а когда RESTful. И хорошо, когда вы можете привести примеры с такими исключениями и войти в дискуссию на эту тему, это показывает глубокое понимание вопроса))
Пытались сделать лучше, получилось раза в разы хуже. Пересобрали из исходников, что остались. Благодарим за обратную связь. Обновлено: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-txuXPI3TB-8.html
+ первая мысль которая пришла в голову. Если ты заинтегрировался с какой то внешней системой, которая тебе с такой большой задержкой должна что то вернуть, то логично что на их стороне должна быть реализация метода, когда внешняя система оповещает ВЕ о смене статуса, как на примере данной задачки. Не совсем конечно понятно зачем такая задачка, ибо в реальности такой кейс из ряда фантастики скорее, да и как отметили другие кандидаты, что тут более рационально использовать брокер
Здравствуйте, спасибо, интересная задачка, хоть и приходилось напрягать слух и еще продираться сквозь музыкальный фон))) Скажите, Никита, а callbackURI для внешней системы может подойти как решение?
Здравствуйте! Спасибо за Вашу обратную связь. С качеством звука будем полностью менять всё) callbackURI для внешней системы может подойти как решение - да, когда внешняя система по готовности вызывает нас (webhook)
Здравствуйте! Были проблемы с сетью, из-за которых качество записи через Zoom пострадало. В будущих выпусках будем менять в лучшую сторону. Спасибо за обратную связь.
Коллеги, были проблемы с сетью, из-за которых качество записи через Zoom пострадало. В будущих выпусках будем менять в лучшую сторону. Спасибо за обратную связь.
Спасибо большое за подкаст! Интересно посмотреть на реальную задачку с собеседования и на то, какие возможны решения. Я даже попробовала сначала сама решить, а потом сравнить с ответом (и приятно было, что почти попала в ответ, данный Никитой). Хотелось бы ещё посмотреть на задачки с собеседований. P.S. Немного технический момент подкаста: иногда во время просмотра музыка очень сбивала и заглушала Никиту. Может, сделать её потише в следующий раз? Или убрать совсем?
Спасибо за Вашу обратную связь! С микрофоном, к сожалению, в этот раз получилась плохая ситуация - Zoom из-за плохой сети у меня порезал качество до .... не самого лучшего. Мы будем перезаписывать этот подкаст позже Сейчас команда работает над организацией записей других подкастов и чек-листа, чтобы проверять соединение у всех участников до старта записи.
Екатерина, большое вам спасибо за видео. Побольше бы таких видосов, с конкретными примерами как у вас, чтобы можно было все повторить, очень круто. Ну и само собой- идея с ушками тоже классная :)
