AM
Я то просто совета спросил на что достойное и зрелое глянуть можно)))))
Мы тут спорим об одной простой вещи
Ниши новых технологий расширяются, старых сужаются
Этот вопрос достоин дискуссии?
Size: a a a
2021 February 13
SB
Так снегопад же на улице, что ещё делать-то 😊
AM
Не спорил не разу)))
GK
Так снегопад же на улице, что ещё делать-то 😊
Тоже верно))
D
Да так и делаю✋😊
можно с целей создания начать. На википедии, например, процитированы цели создания YAML. Из них уже можно какие-то выводы по применимости делать
GK
Nikolay
Вот тут интересная картинка https://mobile.twitter.com/frederickaplan/status/996371431398223872
Любой маркетолог скажет, что в заголовке должна быть какая-нибудь херня порождающая эмоции
Но если заголовок соответствует сути доклада, то доклад странный
Но если заголовок соответствует сути доклада, то доклад странный
GK
Просто API очень разный.
N
Мой вопрос о другом. Переформулирую. Кто либо в своей практике при формулировании решений, выполнял сравнительный анализ форматов (xml, json, и т.д.)? Кто либо этот делал и делает ли? Или все формально подходят к этому вопросу? Пример: делаем на xml. Почему? Потому что я так решил. Или потому что я знаю этот формат.
Таких статей много. Вот например одна из них https://www.google.com/amp/s/hackr.io/blog/json-vs-xml/amp
GK
Конечно в REST (любого уровня зрелости) вряд-ли кому в голову придёт использовать xml
Число REST API растёт. Конечно на графиках JSON будет расти
Число REST API растёт. Конечно на графиках JSON будет расти
GK
Кстати, что касается Rest API Maturity Model
Думаю, Ричардсон ошибся
На самом деле речь о HTTP API Maturity Model наверно. Или Web API
Думаю, Ричардсон ошибся
На самом деле речь о HTTP API Maturity Model наверно. Или Web API
GK
XML для REST не подходит как минимум по двум причинам:
- у него на единицу полезной информации приходится больше "разметки", то есть сообщения в xml "тяжелее"
- xml трудно парсить с помощью JS, а значительно число REST клиентов - фронты
- у него на единицу полезной информации приходится больше "разметки", то есть сообщения в xml "тяжелее"
- xml трудно парсить с помощью JS, а значительно число REST клиентов - фронты
GK
Молодец, мужик, сделал доклад с громким названием.
p
Alexey Mergasov
К экосистеме джава вопросов нет. Я понимаю как там все функционирует. Меня интересует именно новые технологии. Имел честь наблюдать развитие 2 проектов. Один по классике j2ee, другой хайповый на микросервисах го кубере и прочих прелестях. Разница в стоимости в порядок. Ребята реально пытались изобрести кучу велосипедов на го. А потом просто все умерло из за невозможности консистентно перетаскивать между цодами перзистант очереди и данных сервисов.
Это могло быть с любым проектом вне зависимости от стека
GK
И ещё xml нужно учить, молодёжь его часто не знает. А мы когда-то WSDL и тем более схемы в блокноте писали)
p
XML для REST не подходит как минимум по двум причинам:
- у него на единицу полезной информации приходится больше "разметки", то есть сообщения в xml "тяжелее"
- xml трудно парсить с помощью JS, а значительно число REST клиентов - фронты
- у него на единицу полезной информации приходится больше "разметки", то есть сообщения в xml "тяжелее"
- xml трудно парсить с помощью JS, а значительно число REST клиентов - фронты
xml выглядит более зрелым, но вот эти <EnableThisAmazingFeature>1</EnableThisAmazingFeature>
раздражают
раздражают
GK
xml выглядит более зрелым, но вот эти <EnableThisAmazingFeature>1</EnableThisAmazingFeature>
раздражают
раздражают
А неймспейсы?)
Но в xml они есть, а в Open API нет
А для валидации (в рамках форматного контроля) пространства имён крайне полезны
Но в xml они есть, а в Open API нет
А для валидации (в рамках форматного контроля) пространства имён крайне полезны
AM
Это могло быть с любым проектом вне зависимости от стека
Естественно, еквивалентность по функциям и требованиям навела на мысли.
PD
Alexey Mergasov
Длинные транзакции были просто не реализуемы.
Ну, это просто не умели их делать, все там реализуемо )
PD
Думаю что речь о том, что поддержки XA (https://en.wikipedia.org/wiki/X/Open_XA) нету, двухфазный коммит не работает. Он и в JTA не всегда хорошо работает, конечно, но он там есть и в некоторых обстоятельствах полезен. Притом, что транзакционными ресурсами могут быть не только БД, но и очереди сообщений, например.
Ну, XA лучше не применять никогда )