Да знает, поскольку маппинг не следует производить на контроллере. Контроллеры должны быть максимально простыми, отвечая за прием запросов и формирование ответов. Путаницы с изоляцией слов в приложении нет. Действительно, можно добавить ещё слой презентатора, например, но наличие этого в статье для начинающего разработчика избыточно, увы). Рад что вы так серьёзно подошли к обсуждению материала)
Продублирую сюда тот факт, что статья написано для начинающих разработчиков, как способ поделиться опытом в написании простых REST API. Я вкладываю в это понятие тот же смысл, что и рядовые джуны.
Здесь нет решения конкретной бизнес-задачи, нет пользовательских сценариев по описанной выше причине.
Я бы обязательно рассказал о проектировании API в чистом виде, без демонстрации реализации, объяснения полезных аннотаций и подходов, будь у меня на то соответствующие компетенции.
Предлагаю вам поделиться своими глубокими познаниями в этой области в рамках статьи. Будет очень интересно ознакомиться
Я привёл довольно простую реализацию, как вариант решения - типизировать Object до String, но речь идет не только об этом, я понимаю. Ваш подход звучит хорошо, пригодится тем, кто захочет воспроизвести статью на практике)
Спасибо за положительный комментарий, согласен что необходимо доработать этот момент, но в текущей итерации не стал, поскольку для понимания базовых принципов такого подхода достаточно.
HATEOAS часто называют “идеологическим требованием” REST, но его применение оправдано только в определённых случаях. Да и с чего вы решили, что гипер-медиа не сочетаемы с инцидентами? Например, в следующих итерациях микросервиса добавлена работа с вложениями и изображениями, которые являются важной их частью.
В данной статье REST выбран как пример из-за его популярности и удобства для начинающих. Это позволяет изучить ключевые концепции API, такие как принципы идемпотентности, стандарты HTTP-методов и коды ответов.
Напомню, что статья называется идеальный REST API. В любом случае, спасибо за то, что заставляете глубже окунуться в тематику.
Мне действительно довольно часто приходится писать научные работы в универе, но не касающихся веб-разработки. Я искренне убеждён, что такой детализированный подход более «дружелюбен» начинающим в этой стезе специалистам. Спасибо за отзыв!
Привет, позднее приложу ссылку к этой статьей или к следующей части. В принципе, приведённого кода должно хватить для самостоятельного воспроизведения.
Спасибо за положительный комментарий. Довольно часто встречаю как сторонников подобного использования advice, так и любителей обрабатывать такие вещи локально. Тут нет единого мнения, да и в большинстве проектов комбинируют оба подхода. Я предлагаю специфичные ошибки для прозрачности обрабатывать локально, а рядовые и повторяющиеся в глобальной вариации. Это обычно обговаривается в команде
В планах покрыть эту тему целиком, но в ближайшее время будет статья на другую тему, не менее интересную)
Для Kafka передавал JWT в хедерах, для gRPC через интерцептор, заполняя метаданные
https://habr.com/ru/companies/ruvds/articles/912502/
Вышла вторая часть с небольшой задержкой)
https://github.com/br0mberg/SupportDesk-IncidentService
Привет, и вышла вторая часть в профиле
https://github.com/br0mberg/SupportDesk-IncidentService
и вторая часть этой статьи вышла в профиле
Всё так, docker образ использовал с ним, пример на github по ссылке в статье, а рассказал про ZooKeeper, так как по сей день используется в legacy
Спасибо, к началу февраля планировал
Да знает, поскольку маппинг не следует производить на контроллере. Контроллеры должны быть максимально простыми, отвечая за прием запросов и формирование ответов. Путаницы с изоляцией слов в приложении нет. Действительно, можно добавить ещё слой презентатора, например, но наличие этого в статье для начинающего разработчика избыточно, увы). Рад что вы так серьёзно подошли к обсуждению материала)
Продублирую сюда тот факт, что статья написано для начинающих разработчиков, как способ поделиться опытом в написании простых REST API. Я вкладываю в это понятие тот же смысл, что и рядовые джуны.
Здесь нет решения конкретной бизнес-задачи, нет пользовательских сценариев по описанной выше причине.
Я бы обязательно рассказал о проектировании API в чистом виде, без демонстрации реализации, объяснения полезных аннотаций и подходов, будь у меня на то соответствующие компетенции.
Предлагаю вам поделиться своими глубокими познаниями в этой области в рамках статьи. Будет очень интересно ознакомиться
Я привёл довольно простую реализацию, как вариант решения - типизировать Object до String, но речь идет не только об этом, я понимаю. Ваш подход звучит хорошо, пригодится тем, кто захочет воспроизвести статью на практике)
Спасибо за положительный комментарий. В следующей части статьи планировал уделить этому время
Спасибо за положительный комментарий, согласен что необходимо доработать этот момент, но в текущей итерации не стал, поскольку для понимания базовых принципов такого подхода достаточно.
HATEOAS часто называют “идеологическим требованием” REST, но его применение оправдано только в определённых случаях. Да и с чего вы решили, что гипер-медиа не сочетаемы с инцидентами? Например, в следующих итерациях микросервиса добавлена работа с вложениями и изображениями, которые являются важной их частью.
В данной статье REST выбран как пример из-за его популярности и удобства для начинающих. Это позволяет изучить ключевые концепции API, такие как принципы идемпотентности, стандарты HTTP-методов и коды ответов.
Напомню, что статья называется идеальный REST API. В любом случае, спасибо за то, что заставляете глубже окунуться в тематику.
Благодарю. Искренне рад, что смог вам помочь)
Мне действительно довольно часто приходится писать научные работы в универе, но не касающихся веб-разработки. Я искренне убеждён, что такой детализированный подход более «дружелюбен» начинающим в этой стезе специалистам. Спасибо за отзыв!
Привет, позднее приложу ссылку к этой статьей или к следующей части. В принципе, приведённого кода должно хватить для самостоятельного воспроизведения.
Благодарю, добавил этот момент в статью!
Спасибо за положительный комментарий. Довольно часто встречаю как сторонников подобного использования advice, так и любителей обрабатывать такие вещи локально. Тут нет единого мнения, да и в большинстве проектов комбинируют оба подхода. Я предлагаю специфичные ошибки для прозрачности обрабатывать локально, а рядовые и повторяющиеся в глобальной вариации. Это обычно обговаривается в команде
Статья фокусируется на основах REST API, но и про версионирование можно добавить)
Отличные рекомендации, спасибо