Comments 22
Спасибо за полезный материал. Мы в настоящее время также реализуем API для нашего сервиса SkyDNS (хотя сначала все-таки появился веб-интерфейс, хе-хе), правильно я понимаю, что для передачи простых структур данных вы рекомендуете использовать REST / JSON, а не Thrift?
Если не гонять большие объемы данных, то требования к эффективности сериализации данных уже не так остры, а значит, уже можно смотреть в сторону json, например, сериализация в который и так есть почти во всех языках.
Еще рекомендую посмотреть в сторону Google Protocol Buffers. Технология во многом похожа на Thrift, и развивается очень динамично.
Еще рекомендую посмотреть в сторону Google Protocol Buffers. Технология во многом похожа на Thrift, и развивается очень динамично.
ИМХО, не всегда стоит добавлять новые синтаксисы. если существует формат который более широко развит/применяется то прежде всего нужно найти аргументы почему не использовать именно его.
Даже если речь идет не о javascript-oriented-side, JSON — легко трансформируется в тот же XML. А дальше делайте с ним все что угодно… и главное быстро!
REST — удобен для визуального восприятия, прозрачности интерфесов и для администрирования сервера.
Даже если речь идет не о javascript-oriented-side, JSON — легко трансформируется в тот же XML. А дальше делайте с ним все что угодно… и главное быстро!
REST — удобен для визуального восприятия, прозрачности интерфесов и для администрирования сервера.
Я знаю, что повторяюсь, но все равно, очень хочется сказать: Спасибо за материал.
1. SOAP кросплатформенный
2. SOAP подходит для передачи бинарных данных, см SOAP XOP — XML-binary Optimized Packaging
3. Проблема приложения, а не протокола
4. В Java есть автоматический биндинг, см Apache CXF
5. SOAP открыт, куча реализаций
6. Проблема приложения, а не протокола
2. SOAP подходит для передачи бинарных данных, см SOAP XOP — XML-binary Optimized Packaging
3. Проблема приложения, а не протокола
4. В Java есть автоматический биндинг, см Apache CXF
5. SOAP открыт, куча реализаций
6. Проблема приложения, а не протокола
Причины, по которым был выбран Thrift в 2007 году, понятны. Мне интересно, сейчас этот выбор был бы таким же или это был бы Protocol Buffers? Из каких соображений?
Тоже интересно сравнение с Protocol Buffers. Хотя бы сравнение по этим 6 пунктам.
Мы сами всерьез Protocol Buffers не изучали, потому что выбор уже однажды был сделан.
Вот пара ссылок по сравнению Protocol Buffers и Thrift:
stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers
stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers
Вот пара ссылок по сравнению Protocol Buffers и Thrift:
stackoverflow.com/questions/69316/biggest-differences-of-thrift-vs-protocol-buffers
stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers
Все сравнения старые и часто синтетические.
Парсер лох :) По самой свежей ссылке старые версии (в скобках указаны актуальные версии)
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 реального проекта на протяжении определенного промежутка времени, гибкость и простота использования, версионность, связка с существующими платформами.
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 реального проекта на протяжении определенного промежутка времени, гибкость и простота использования, версионность, связка с существующими платформами.
Я правильно понимаю что Thrift можно ставить примерно в один ряд с ProtocolBuffers, ASN и SOAP?
Т.е. язык описания передаваемых данных и генераторы кода для сериализации/десериализации?
Т.е. язык описания передаваемых данных и генераторы кода для сериализации/десериализации?
Хорошо, что пофиксили issues.apache.org/jira/browse/THRIFT-601
Когда я сморел на thrift прошлый раз, отказался от него по этой причине. Собственно поэтому cassandra я тоже не выбрал.
Когда я сморел на thrift прошлый раз, отказался от него по этой причине. Собственно поэтому cassandra я тоже не выбрал.
У вас Thrift используется как RPC, или только для сериализации данных при передаче через HTTP?
Sign up to leave a comment.
Техноблог: почему Evernote выбрал Apache Thrift для построения своего API