Какие есть реальные преимущества написания Rest API на Java?

Либо я глупый, либо вопрос. Унылый CRUD с поддержкой авторизации, ролей и всего вот этого вот делается за 15 минут даже без спринга, на голом томкате; в го, пыхе и ноде, полагаю, ещё быстрее. На чём написан остальной код и подо что есть настроенный контейнер - на том и пиши 0_о

А что конкретно ты хочешь услышать? Я сомневаюсь, что найдётся много лорчан, которые разрабатывали что-то серьёзно и на спринге, и, допустим, на джанге, и на ларавеле.

Я писал синхронные Web API, асинхронные до и после asyncio на Python. Небольшую апишку на Go и чуть чуть раширял готовую на PHP. Умею в JS и немного ноду, но апишки на пих не писал, Java когда-то учил, но писал на ней довольно мало (спринг в глаза не видел, но вполне представляю что это).

Могу потеоретизировать.

Сам процесс на жабе и на пыхе (в условиях любого фреймворка типа симфони) мало отличается. А вот далее с пыхом ты огребаешь все радости скриптоты и динамической типизации (для последнего пыха менее актуально). Думаю остальные тоже на начальном этапе мало отличаются.

А зачем тебе рест? Он же убогий.

Я спрашиваю не на чем мне писать, конкретной задачи нет. Просто знаю, что кто-то пилит API на java - вот и интересно стало, в каких случаях использовать java было бы предпочтительнее и почему.

На этом всем и я пишу, и Java тоже учил когда-то еще в универе) Хотелось просто услышать java-разрабов :)

А что как не рест?

1. возможность затянуть разработку
2. спихнуть ответственность на тех кто это пишет
3. вынудить поддерживать этот кусок дерьма вместо того чтобы переписать его

gRPC JSON-RPC

Либо я глупый, либо вопрос. Унылый CRUD с поддержкой авторизации, ролей и всего вот этого вот делается за 15 минут даже без спринга

Тут разговор про REST, это значит нужно из URI парсить путь, аргументы, параметры, их нужно валидировать, плюс еще библиотеки для сериализации/десераиализации JSON. Короче без spring получится свой фреймворк начиная с DispatcherServlet. Тут недостаток в количестве не проверенного кода, который никто кроме автора поддерживать не захочет.

Это только в джаве разве такие киллер-фичи?

Не юзал. Сейчас прочитал, но не понял: а в чем профит? Особого удобства не вижу, в реальных проектах тоже ни разу не натыкался. Для той же Django последние коммиты в библиотеку для JSON-RPC были аж 7 лет (вот еще - 5 лет назад) назад, что намекает на то, что это как бы не развивается особо и не востребовано.

Шо ты как ребёнок? На Java пишут REST только тогда, когда уже куча кода написана на JAVA, в других случаях джаву и не берут - она жрёт как не в себя. Java и Ruby - самые жрущие по памяти языки, так java хоть работает быстро

Если ты в одну морду пишешь - java не для тебя. Для тебя python, node, Go, Dart, php. Тут вопрос о времени разработки стоит обширно, и скриптота с кучей либ на первом месте всегда

Go

Убогий многословный язык без исключений. На Java писать код раза в 3 быстрей.

NodeJS/Python/Php

Если речь о JS, нетипизированная параша, на Java писать код раз в 5 быстрей и в 10 раз меньше багов.

Эти фичи в питон привносит джанга, а пых он в принципе такой, но ларавель выводит это на новый уровень.

На Java писать код раза в 3 быстрей

Чушь несусветная, эта многословная дрянь и «быстрее» в одном предложении могут быть только в анекдоте.

То, что удобно. Увы, но REST — это как тот глобус. Всем хорош, но вот реальная сова на него не натягивается.

Многословность не мешает писать код быстрей. Скорей наоборот, помогает. Ты же не машинистка, которая ограничена скоростью клавиатуры.

Под словом REST обычно понимают любой HTTP/JSON API. На измышления Филдинга давно всем плевать.

Говённый язык и бойлерплейтинг отвлекают от дела.

Поэтому я и говорю, что на Java писать куда быстрей, чем на Go.

В Go как раз всё лаконично и есть нормальные батарейки в отличие от.

само набирание текста во времени разработки составляет наверное тысячную процента и на стоимость разработки не влияет. синтаксис, вербозность - это никак вообще не влияет.

и есть нормальные батарейки

Например?

Да хотя бы простейшая фича — вычитать файл целиком, она есть в стандартной библиотеке, и это дофига приятно.

Представь стандартную библиотку питона, только без мусора, лучше вдвое и с байтами. Это Go.

Ещё как влияет. На этом просто не хочется писать. Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.

String FileUtils.readFileToString(file)
byte[] FileUtils.toByteArray(file)

А чем они хуже?

Но я посмотрел, действительно неплохо. Правда Java сильна сторонними библиотеками как мне видится.

Ещё как влияет.

Очевидно, на джаве ты не писал никогда. Если бы писал хоть немного, то так бы не говорил.

Тем более, понятно, что ты не писал проектов больше хелловорлда, которые реально работают и поддерживаются.

Ты кукаретик-пустослов, мнение которого ничего не значит.

язык без исключений не может быть лаконичным.

тем более го вообще уродец без дженериков и нормальной поддержки многопоточности (в чем Java лидер).

Не только. Но в джаве они действительно киллер.

Ты на го-то писал? Го уродлив, но упреки его в отсутствии нормальной поддержки многопоточности, когда именно многопоточность из коробки и есть основная киллер-фича Го, лишь показывают твою некомпетентность.

В 80% случаях ты будешь городить на ресте убогую замену рпц. Поэтому есть смысл сразу брать рпц.

И вот так на каждый чих что-то извне тащить, класс, да?

Очевидно только, что ты трепло и петушара.

Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной рабами лишь бы не работать

fixed

а ты, со своим «опытом» на жабе, лучше бы молчал

По теме: лучше чем Java full stack ты в 2020 году не найдешь. Спросишь «чем лучше?» – по всем направлениям лучше чем всё остальное. И если кодер попадет под трамвай, следующего можно найти на улице за 5 минут.

Правда с hibernate я бы поспорил. Оно часто overkill и не нужно как и всякие Spring Data JPA. Проще писать запросы в базу руками с jdbc template на перевес. Так понятней и «магии» в коде нет.

Насчёт говноязыка согласен, не надо его использовать. Но Go ещё хуже.

Э-э-э… мсье сторонник плоских неймспейсов?

Я не писал REST на всем прочем, но все прозаично, жабадевелоперов много, аноним прав что можно спокойно найти людей на рынке труда с опытом.
Еще spring фреймворк не сильно ломает обратную совместимость, например там все еще есть старый способ создания транзакций программным способом, все классы на месте, хотя последний раз я им пользовался наверное лет 10 назад.

У JVM есть технические преимущества перед Python и Node - настоящий мультипоток, со всеми примитивами и подходами для работы с разделенными ресурсами.

Из всего перечисленного у тебя только Go и Java статически типизированные языки, для многих это решающий фактор при выборе инструмента.

Сторонник удобства и поддерживаемости. Когда у тебя в проекте десятки зависимостей, а у каждой зависимости ещё чёрт знает сколько, ты уже не то, что не можешь гарантировать, что проект у тебя через год-два соберётся, ты уже сейчас не контролируешь то, что у тебя в прод попадает. Удачи со 100% покрытием при таком подходе.

Maven, ant? Не, не слышал.

А, так ты жертва 100% покрытия и прочего Clean Code… ок

Так наоборот, я не сторонник. Но когда у тебя огромное количество сторонних библиотек используется, тебе хочешь, ни хочешь, а придётся всё это покрывать тестами. Рано или поздно оно сломается, и без тестов ты об этом узнаешь, скорее всего, уже раскатив это на прод.

Типичный Goшник detected.

В нормальных проектах не делают импорт по гитхаб-урлу. Там в проект добавляют конкретные версии. Которые через год-два не поменяются.

Ну и, да, 100% покрытие — это такой символ веры из мира динамически и слабо типизированных языков, где без тестов невозможно даже понять, должно ли то, что твой сосед написал, работать в твоём случае.

Не знаю, что такое «jdbc template», но, исходя из моего опыта разработки на Php/Python/Go, могу сказать, что писать запросы в базу руками - то еще извращенство. Я не сторонник ORM, но квери-билдер и дата-гидратор (чтобы результаты запроса маппить на объекты), как минимум, нужны. Потому в противном случае при куче фильтров придется конкатенировать строку с запросом руками.

Причём Go с его interface {} слабо подходит на роль статически типизированного.

Php и Python разве сильно меньше жрут? Goшка, понятное, дело меньше - это ясно.

Что мешает зафиксировать версию в go.mod?

это такой символ веры из мира динамически и слабо типизированных языков

Ну как бы те же проекты на Java активно покрывают тестами. В ней слабая типизация?

Ты, кажется, не понимаешь что такое «сторонние библиотеки» в java мире. Это очень хорошо оттестенный код. Сделан он для того, чтобы не строили велосипедов. Через maven я обновляю версии примерно раз в 2 года, ито хз зачем. Просто чтобы up to date было. Итак все работает.

Например: покрывать тестами какой-нибудь apache poi нет надобности. У него огромное комьюнити и багов там почти нет.

Если ты в одну морду пишешь - java не для тебя. Для тебя python, node, Go, Dart, php.

Если с Python и Php ясно, то на Go разве проще в одну морду писать? Там же многие вещи реально приходится вручную делать. Фреймворков типа Laravel/Django и т.п. нет, только Gin/Gonic по сути. Если в Django подключил либу - и есть у твоей APIшки JWT (даже с возможностью добавлять токены в черный список) тут же, то на Go это все пилишь руками. Да, есть для Gin/Gonic либа, но она реализует JWT одним токеном без возможности рефреша. То есть по сути половину этой задачи пилишь руками. Так ли уж проще в одну морду?

Не знаю, что такое «jdbc template»

Так погугли.

но квери-билдер и дата-гидратор (чтобы результаты запроса маппить на объекты), как минимум, нужны

Там много магии. У меня 50% работы это рапорты. В типичном рапорте задействованы примерно все таблицы, что есть. Попробуй это на ORM напиши. Получится такой медленный динозавр-франкинштейн, что рапорта клиенты будут по 30 минут ждать.

Потому в противном случае при куче фильтров придется конкатенировать строку с запросом руками.

Так и делаю. Зато знаю что именно делает запрос, потому что сам его пишу и оптимизирую.