SOAP и GraphQL тоже реализации REST? Или все-таки HTTP это транспортный протокол (читай уровень) а REAT API, JSON API, SOAP и GrathQL протокол приложения.
Пожалуйста, почитайте про модель OSI. Я конечно сам раньше плавал в понимании, что есть, что, но фраза - "HTTP — это реализация стиля REST" - это что-то за гранью.
Ну это не правда, там много чего кастомизируется. Логика спокойно наращивается, притом довольно чистым кодом т.к. завязана на события CRUD. + Если нужно как-то изменять представление сущностей, там вроде работает JPA Projections.
Исходя из примеров кода, я вижу что для любого не CRUD действия, нужно переопределять метод или создавать промежуточный сервис в цепочку запрос-ответ. Я имею в виду, что всё, что не заложено в "дженерик" реализацию, нужно всё равно писать, но если это не нужно, то как бы есть уже готовое решение (Data REST).
Да, это Hateoas и RESTFull, где не так удобны некоторые операции. Но если задача стоит уменьшить кодовую базу (дублирование) + время разработки, я думаю это валидный способ, воспользоваться существующим инструментом.
А если задача построить большой монолит, то как бы я предполагаю, что хороший архитектор подумает о разработчиках\коллегах и базовые одинаковые действия выведет в слой абстракции. Всегда же приятнее, удобно добавлять фичи, а не страдать и рефакторить бесконечно или колупаться в копипастах с мыслями "Где же не переименовал\добавил\удалил что-то?".
Есть ещё один момент с тем как сообщество разработчиков влияет на принятие решения в архитектуре.
Иногда его называют best practics, а иногда desing patterns. Но по сути это какие-то решения которые кто-то придумал, увидел что они удобны и рассказал всем. И если вдруг этот человек имеет авторитет в сообществе, всегда найдутся люди которые слепо поверят и будут с пеной у рта доказать, что нужно делать так и только так. А потом проекты которым пару лет уже нарекаются legacy, потому, что YAGNI и DRY, потому, что так было написано в блоке важного разработчика, потому, что так говорит умная книга 20-летней давности.
Очень важно понимать вайб заказчика и домен с которым работаешь. Это позволяет уже не слепо писать что-то, а по настоящему предусматривать будущее расширения проекта. Ну и важно думать про YAGNI и DRY не только с точки зрения кода и архитектуры, а сточки зрения процесса который описывает информационная система.
А собственно в чем вопрос? Беглый гуглеж показал что в Kotlin нет своего ORM подобного JPA (возможно я плохо искал). Но есть аналог Jooq. Если вам не нравится один инструмент есть другой. Зачем страдать? Пользуйтесь чем умеете и не страдайте.
Каждый инструмент имеет проблемы и недостатки, поэтому их и много. Важно уметь работать с разными и понимать какой инструмент нужен в определенной ситуации.
Я видел XML на HTTP. Welcome to Java Enterprise World.
SOAP и GraphQL тоже реализации REST? Или все-таки HTTP это транспортный протокол (читай уровень) а REAT API, JSON API, SOAP и GrathQL протокол приложения.
Пожалуйста, почитайте про модель OSI. Я конечно сам раньше плавал в понимании, что есть, что, но фраза - "HTTP — это реализация стиля REST" - это что-то за гранью.
Ну это не правда, там много чего кастомизируется. Логика спокойно наращивается, притом довольно чистым кодом т.к. завязана на события CRUD. + Если нужно как-то изменять представление сущностей, там вроде работает JPA Projections.
Исходя из примеров кода, я вижу что для любого не CRUD действия, нужно переопределять метод или создавать промежуточный сервис в цепочку запрос-ответ. Я имею в виду, что всё, что не заложено в "дженерик" реализацию, нужно всё равно писать, но если это не нужно, то как бы есть уже готовое решение (Data REST).
Да, это Hateoas и RESTFull, где не так удобны некоторые операции. Но если задача стоит уменьшить кодовую базу (дублирование) + время разработки, я думаю это валидный способ, воспользоваться существующим инструментом.
А если задача построить большой монолит, то как бы я предполагаю, что хороший архитектор подумает о разработчиках\коллегах и базовые одинаковые действия выведет в слой абстракции.
Всегда же приятнее, удобно добавлять фичи, а не страдать и рефакторить бесконечно или колупаться в копипастах с мыслями "Где же не переименовал\добавил\удалил что-то?".
Я может не уловил сути. Если у нас простой CRUD с возможностью кастомизации, тогда чем к задаче не подходит Spring Data REST?
Есть ещё один момент с тем как сообщество разработчиков влияет на принятие решения в архитектуре.
Иногда его называют best practics, а иногда desing patterns. Но по сути это какие-то решения которые кто-то придумал, увидел что они удобны и рассказал всем. И если вдруг этот человек имеет авторитет в сообществе, всегда найдутся люди которые слепо поверят и будут с пеной у рта доказать, что нужно делать так и только так. А потом проекты которым пару лет уже нарекаются legacy, потому, что YAGNI и DRY, потому, что так было написано в блоке важного разработчика, потому, что так говорит умная книга 20-летней давности.
Очень важно понимать вайб заказчика и домен с которым работаешь. Это позволяет уже не слепо писать что-то, а по настоящему предусматривать будущее расширения проекта.
Ну и важно думать про YAGNI и DRY не только с точки зрения кода и архитектуры, а сточки зрения процесса который описывает информационная система.
А собственно в чем вопрос?
Беглый гуглеж показал что в Kotlin нет своего ORM подобного JPA (возможно я плохо искал). Но есть аналог Jooq.
Если вам не нравится один инструмент есть другой.
Зачем страдать? Пользуйтесь чем умеете и не страдайте.
Каждый инструмент имеет проблемы и недостатки, поэтому их и много. Важно уметь работать с разными и понимать какой инструмент нужен в определенной ситуации.
Мы модифицируем поле в приделах класса (пускай и в статическом методе), здесь нет нарушения конвенции.