Pull to refresh

Comments 16

Использую похожую схему для генерации типов и сервисов в TypeScript

В TS прям эта же схема работает просто как сказка, вообще без лишних телодвижений

А мы по спринговым контроллерам вот такой штукой генерим: apina.evident.fi. Конечно не столь гибко как тут описано, но все же рабочий вариант.
А вот двадцать лет назад, когда компоненты приложений через веб общались по протоколу SOAP, кодогенераторы, автоматически создающие болванку клиента, выдергивая описание из API, были встроены в IDE «из коробки»…
UFO just landed and posted this here

Закопали, потому что обещали Simple, а получилось наоборот.

Так себе сарказм, если честно. Закопали не потому, что оно там такое уж плохое было. Да, сложное и громоздкое по сравнению с JSON+REST. Но с точки зрения программиста сериализовать объект в XML — это ровно одна строчка, как и JSON. Только к этому прилагалось куда больше автоматизации, и контроль типов.
Но закопали потому, что появилась потребность в транспортном протоколе для веб-приложений, а веб совместными усилиями разработчиков браузеров и консорциума W3C развивался не в сторону «создать платформу для разработки приложений, как требует рынок», а в сторону «нахерачить побольше атрибутов CSS и развлекаться, получая побочные эффекты от их комбинаций». И в итоге приложения-то разрабатывать было нужно, а никакого вменяемого инструментария/библиотек для этого не было. И сложность XML, которую на десктопных приложениях никто и не замечал, веб-разработчикам стала реальной проблемой.

Простите, а в чём сложность XML для веб-разработчиков? HTML по нотации и есть XML... т.е. очень странно что человек понимает вложенность тега "table", "tr" и работу с их атрибутами, но мозг взрывается когда нужно работать с XML с данными карточки пользователя.

Помню как на десктопе здорово было указать адрес soap сервиса в VS и получит готовый клиент - просто вызывай методы.

Сложность была не в том, что они не могли прочитать и понять XML, а в том, что им приходилось писать код для чтения и записи XML, в то время как в десктопных IDE он даже 20 лет назад уже генерировался автоматически.

Вы, конечно, сравнили хорошо проработанный индустриальный стандарт с поделкой одной компании, склепанной на коленках и созданной с целью продвижения собственного коммерческого решения.
Про SOAP на время забыли, потому что IT отрасль массово заполонили JS-ники, для которых концепция декларации типов и транспорто-независимого протокола была непосильно сложной для их межушного нервного узла. "Зачем нам типы, у нас есть JSON и HTTP!".
Однако когда к новоиспеченному "API" подоспел серьезынй бизнес, потребовалась более строгая форма декларировать контракты взаимодействия между системами. И как результат в данный момент мы видим стихийное переизобретение велосипеда SOAP с нуля подручными и доступными для понимания средствами.

SOAP еще Инженеры разрабатывали. сегодня, после нашествия хипстоты, ломаем глаза об так называемые json-схемы.

А есть ли что-то подобное для дарт ?

По мойму этот OpenAPI унылая шляпа, столько некрасивого мусора со всех сторон. Я вообще "не пишу код для взаимодействия с для взаимодействия с бэкендом" равно как и сам фронт-енд, а получаю его сразу из моих данных с помощью авто-фронтэндера. https://github.com/Claus1/unigui если что.

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

А по поводу унылости - интересное мнение) я последний год использую gRPC и он мне очень нравится.

Sign up to leave a comment.

Articles