Да знает, поскольку маппинг не следует производить на контроллере. Контроллеры должны быть максимально простыми, отвечая за прием запросов и формирование ответов. Путаницы с изоляцией слов в приложении нет. Действительно, можно добавить ещё слой презентатора, например, но наличие этого в статье для начинающего разработчика избыточно, увы). Рад что вы так серьёзно подошли к обсуждению материала)
Продублирую сюда тот факт, что статья написано для начинающих разработчиков, как способ поделиться опытом в написании простых REST API. Я вкладываю в это понятие тот же смысл, что и рядовые джуны.
Здесь нет решения конкретной бизнес-задачи, нет пользовательских сценариев по описанной выше причине.
Я бы обязательно рассказал о проектировании API в чистом виде, без демонстрации реализации, объяснения полезных аннотаций и подходов, будь у меня на то соответствующие компетенции.
Предлагаю вам поделиться своими глубокими познаниями в этой области в рамках статьи. Будет очень интересно ознакомиться
Я привёл довольно простую реализацию, как вариант решения - типизировать Object до String, но речь идет не только об этом, я понимаю. Ваш подход звучит хорошо, пригодится тем, кто захочет воспроизвести статью на практике)
Спасибо за положительный комментарий, согласен что необходимо доработать этот момент, но в текущей итерации не стал, поскольку для понимания базовых принципов такого подхода достаточно.
HATEOAS часто называют “идеологическим требованием” REST, но его применение оправдано только в определённых случаях. Да и с чего вы решили, что гипер-медиа не сочетаемы с инцидентами? Например, в следующих итерациях микросервиса добавлена работа с вложениями и изображениями, которые являются важной их частью.
В данной статье REST выбран как пример из-за его популярности и удобства для начинающих. Это позволяет изучить ключевые концепции API, такие как принципы идемпотентности, стандарты HTTP-методов и коды ответов.
Напомню, что статья называется идеальный REST API. В любом случае, спасибо за то, что заставляете глубже окунуться в тематику.
Мне действительно довольно часто приходится писать научные работы в универе, но не касающихся веб-разработки. Я искренне убеждён, что такой детализированный подход более «дружелюбен» начинающим в этой стезе специалистам. Спасибо за отзыв!
Привет, позднее приложу ссылку к этой статьей или к следующей части. В принципе, приведённого кода должно хватить для самостоятельного воспроизведения.
Спасибо за положительный комментарий. Довольно часто встречаю как сторонников подобного использования advice, так и любителей обрабатывать такие вещи локально. Тут нет единого мнения, да и в большинстве проектов комбинируют оба подхода. Я предлагаю специфичные ошибки для прозрачности обрабатывать локально, а рядовые и повторяющиеся в глобальной вариации. Это обычно обговаривается в команде
Привет! С JHipster пока не знаком, но видел, как API генерируют с помощью Amplicode — выглядит довольно удобно. Думаю, использование таких инструментов действительно ускоряет разработку, особенно в руках опытного разработчика.
Однако, в статье я ставлю перед собой другую цель: показать, как писать REST API вручную, с нуля. Это особенно полезно для тех, кто только знакомится с основами, или хочет сравнить свой подход с реализованным способом в статье. Такой процесс помогает лучше понять тонкости разработки и получить полный контроль над архитектурой.
Спасибо за идею! Возможно, стоит рассмотреть генераторы в будущих статьях для сравнения.
Привет, большое спасибо за положительный комментарий! Помню, когда писал свой самый первый pet-проект, колебался на выборе между Dto и DTO. Пришёл к тому, что IncidentDto больше подходит под единообразие стиля. Стараюсь придерживаться одного общепринятого, не считая специфичных вещей, таких как именования proto-файлов, например. Насчёт именования в мапперах — тот же стиль, в духе: toEntity, toDto, toDtoWithDetails.
На самом деле, вашему мнению имеет место быть и не только, я бы сказал, что вы правы. Простой пример: возвращать User без обёртки с хэшом пароля - так себе идея. В моём случае не было конфиденциальной информации, которую нужно сокрыть, но безусловно нужно принять ваше замечание во внимание. Спасибо, я доработаю этот момент!
Привет, клиенту может быть важно получить ресурс без обёрток, например, id для отслеживания состояния созданного инцидента в будущем или привязать его к другим сущностям
Да знает, поскольку маппинг не следует производить на контроллере. Контроллеры должны быть максимально простыми, отвечая за прием запросов и формирование ответов. Путаницы с изоляцией слов в приложении нет. Действительно, можно добавить ещё слой презентатора, например, но наличие этого в статье для начинающего разработчика избыточно, увы). Рад что вы так серьёзно подошли к обсуждению материала)
Продублирую сюда тот факт, что статья написано для начинающих разработчиков, как способ поделиться опытом в написании простых REST API. Я вкладываю в это понятие тот же смысл, что и рядовые джуны.
Здесь нет решения конкретной бизнес-задачи, нет пользовательских сценариев по описанной выше причине.
Я бы обязательно рассказал о проектировании API в чистом виде, без демонстрации реализации, объяснения полезных аннотаций и подходов, будь у меня на то соответствующие компетенции.
Предлагаю вам поделиться своими глубокими познаниями в этой области в рамках статьи. Будет очень интересно ознакомиться
Я привёл довольно простую реализацию, как вариант решения - типизировать Object до String, но речь идет не только об этом, я понимаю. Ваш подход звучит хорошо, пригодится тем, кто захочет воспроизвести статью на практике)
Спасибо за положительный комментарий. В следующей части статьи планировал уделить этому время
Спасибо за положительный комментарий, согласен что необходимо доработать этот момент, но в текущей итерации не стал, поскольку для понимания базовых принципов такого подхода достаточно.
HATEOAS часто называют “идеологическим требованием” REST, но его применение оправдано только в определённых случаях. Да и с чего вы решили, что гипер-медиа не сочетаемы с инцидентами? Например, в следующих итерациях микросервиса добавлена работа с вложениями и изображениями, которые являются важной их частью.
В данной статье REST выбран как пример из-за его популярности и удобства для начинающих. Это позволяет изучить ключевые концепции API, такие как принципы идемпотентности, стандарты HTTP-методов и коды ответов.
Напомню, что статья называется идеальный REST API. В любом случае, спасибо за то, что заставляете глубже окунуться в тематику.
Благодарю. Искренне рад, что смог вам помочь)
Мне действительно довольно часто приходится писать научные работы в универе, но не касающихся веб-разработки. Я искренне убеждён, что такой детализированный подход более «дружелюбен» начинающим в этой стезе специалистам. Спасибо за отзыв!
Привет, позднее приложу ссылку к этой статьей или к следующей части. В принципе, приведённого кода должно хватить для самостоятельного воспроизведения.
Благодарю, добавил этот момент в статью!
Спасибо за положительный комментарий. Довольно часто встречаю как сторонников подобного использования advice, так и любителей обрабатывать такие вещи локально. Тут нет единого мнения, да и в большинстве проектов комбинируют оба подхода. Я предлагаю специфичные ошибки для прозрачности обрабатывать локально, а рядовые и повторяющиеся в глобальной вариации. Это обычно обговаривается в команде
Статья фокусируется на основах REST API, но и про версионирование можно добавить)
Отличные рекомендации, спасибо
Спасибо, это определённо внесло ясности. Ради таких комментариев, я и пишу статьи, чтобы обратить на проблему внимание с других сторон
Привет! С JHipster пока не знаком, но видел, как API генерируют с помощью Amplicode — выглядит довольно удобно. Думаю, использование таких инструментов действительно ускоряет разработку, особенно в руках опытного разработчика.
Однако, в статье я ставлю перед собой другую цель: показать, как писать REST API вручную, с нуля. Это особенно полезно для тех, кто только знакомится с основами, или хочет сравнить свой подход с реализованным способом в статье. Такой процесс помогает лучше понять тонкости разработки и получить полный контроль над архитектурой.
Спасибо за идею! Возможно, стоит рассмотреть генераторы в будущих статьях для сравнения.
Привет, большое спасибо за положительный комментарий! Помню, когда писал свой самый первый pet-проект, колебался на выборе между Dto и DTO. Пришёл к тому, что
IncidentDtoбольше подходит под единообразие стиля. Стараюсь придерживаться одного общепринятого, не считая специфичных вещей, таких как именования proto-файлов, например. Насчёт именования в мапперах — тот же стиль, в духе:toEntity,toDto,toDtoWithDetails.На самом деле, вашему мнению имеет место быть и не только, я бы сказал, что вы правы. Простой пример: возвращать User без обёртки с хэшом пароля - так себе идея.
В моём случае не было конфиденциальной информации, которую нужно сокрыть, но безусловно нужно принять ваше замечание во внимание. Спасибо, я доработаю этот момент!
Привет, клиенту может быть важно получить ресурс без обёрток, например, id для отслеживания состояния созданного инцидента в будущем или привязать его к другим сущностям
Да, для объективности исследования взял стороннюю python модель
Спасибо за положительный комментарий, если будут какие-то вопросы обращайтесь, помогу