How to become an author
Search
Write a publication
Pull to refresh

Comments 22

Спасибо за полезный материал. Мы в настоящее время также реализуем API для нашего сервиса SkyDNS (хотя сначала все-таки появился веб-интерфейс, хе-хе), правильно я понимаю, что для передачи простых структур данных вы рекомендуете использовать REST / JSON, а не Thrift?
Total votes 5: ↑4 and ↓1+3
Если не гонять большие объемы данных, то требования к эффективности сериализации данных уже не так остры, а значит, уже можно смотреть в сторону json, например, сериализация в который и так есть почти во всех языках.

Еще рекомендую посмотреть в сторону Google Protocol Buffers. Технология во многом похожа на Thrift, и развивается очень динамично.
Total votes 3: ↑3 and ↓0+3
ИМХО, не всегда стоит добавлять новые синтаксисы. если существует формат который более широко развит/применяется то прежде всего нужно найти аргументы почему не использовать именно его.

Даже если речь идет не о javascript-oriented-side, JSON — легко трансформируется в тот же XML. А дальше делайте с ним все что угодно… и главное быстро!

REST — удобен для визуального восприятия, прозрачности интерфесов и для администрирования сервера.
This comment wasn’t rated yet0
Я знаю, что повторяюсь, но все равно, очень хочется сказать: Спасибо за материал.
Total votes 2: ↑2 and ↓0+2
Вот здесь Лев Валкин описывал недостаток спецификации этого протокола.
Total votes 2: ↑2 and ↓0+2
1. SOAP кросплатформенный
2. SOAP подходит для передачи бинарных данных, см SOAP XOP — XML-binary Optimized Packaging
3. Проблема приложения, а не протокола
4. В Java есть автоматический биндинг, см Apache CXF
5. SOAP открыт, куча реализаций
6. Проблема приложения, а не протокола
Total votes 3: ↑2 and ↓1+1
UFO just landed and posted this here
Какие ваши доказательства? (с)
This comment wasn’t rated yet0
а еще soap убивает своей тяжеловесностью половину веб-приложений на смартфонах.
This comment wasn’t rated yet0
Причины, по которым был выбран Thrift в 2007 году, понятны. Мне интересно, сейчас этот выбор был бы таким же или это был бы Protocol Buffers? Из каких соображений?
Total votes 1: ↑1 and ↓0+1
Тоже интересно сравнение с Protocol Buffers. Хотя бы сравнение по этим 6 пунктам.
This comment wasn’t rated yet0
Все сравнения старые и часто синтетические.
This comment wasn’t rated yet0
Парсер лох :) По самой свежей ссылке старые версии (в скобках указаны актуальные версии)
github.com/eishay/jvm-serializers/wiki/

protobuf 2.3.0 (2.4.1)
thrift 0.4.0 (0.6.1)
avro 1.3.2 (1.5.1)
kryo 1.03 (1.04)
hessian 4.0.3 (4.0.7)
scala 2.8.0-rc1 (2.9.0.1)
google-gson 1.6 (1.7.1)
jackson 1.7.1 (1.8.1)
protostuff 1.0.0.M7 (1.0.0)
woodstox 4.0.7 (4.1.1)
aalto 0.9.5 (0.9.7)
fast-infoset 1.2.6 (1.2.10)

Хотя конечно больше интересует не скорость тем более в java, а скорость в Production реального проекта на протяжении определенного промежутка времени, гибкость и простота использования, версионность, связка с существующими платформами.
This comment wasn’t rated yet0
Я правильно понимаю что Thrift можно ставить примерно в один ряд с ProtocolBuffers, ASN и SOAP?
Т.е. язык описания передаваемых данных и генераторы кода для сериализации/десериализации?
This comment wasn’t rated yet0
Хорошо, что пофиксили issues.apache.org/jira/browse/THRIFT-601
Когда я сморел на thrift прошлый раз, отказался от него по этой причине. Собственно поэтому cassandra я тоже не выбрал.
This comment wasn’t rated yet0
У вас Thrift используется как RPC, или только для сериализации данных при передаче через HTTP?
This comment wasn’t rated yet0
а если клиент сидит за http proxy? thrift вроде через прокси ходить не умеет
This comment wasn’t rated yet0
Умеет, если используется HTTP-транспорт (у нас именно так).
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr