avatar
RESTful 到底有啥优势呢# JobHunting - 待字闺中
p*y
1
【 以下文字转载自 Vegetarianism 俱乐部 】
发信人: purity (purity), 信区: Vegetarianism
标 题: 男人健康8道防线 zt
发信站: BBS 未名空间站 (Thu Nov 3 14:44:13 2011, 美东)
男人看似比女人强壮,可往往关键时刻,更容易被疾病所击倒。世界卫生组织流行病学
调查显示,男人心脏比女人更脆弱,中国男人出现心脑血 管疾病的几率是女人的两倍多
。男人肠胃也比女人脆弱:临床专家发现,15—50岁的男人,肠胃病发病率是女人的6.
2倍。频繁的社交让男人极易感染各种肝 炎病毒,酒桌上推杯换盏更是带来不可逆转的
肝损伤。再加上前列腺问题,给男人健康带来巨大的隐患。
但在关心自身健康方面,男人往往表现的比较迟钝。中国80%的重病男性在调查中承认,
因为长期忽视健康小问题,所以让身体再三透支。《生命时报》近日采访了多名权威专
家,请他们帮男人健康筑起八道防线。
一号防线:40岁后别吃肥肉。
美国人把心血管疾病称为"男性病",他们发现,四五十岁、大腹便便、抽烟的男人,大
多"怀揣"着一份心血管疾病诊断书。爱尔兰国立大学医学专家建议,要减少这一现象,
女人一定要管好丈夫的嘴,帮男人戒烟,再写一份护心食谱。
中国农业大学食品学院副教授范志红指出,男人最爱吃肉和油炸食品,对动物脂肪的偏
爱会导致油脂过多,沉淀在血管上造成动脉硬化,形成血栓。要想管住男人的嘴,就要
让他们多豆制品、坚果、燕麦和大蒜,这些都是心血管疾病"克星"。此外,还要少吃盐,
多吃水果,40岁以后不要吃动物内脏和肥肉。
二号防线:包里放瓶急救药。
在由心血管疾病导致的猝死中,男性的比例要远远高于女性。对于肥胖、抽烟和长期处
于疲劳紧张状态的男性来说,也许在打球、洗澡、开会或吃饭过程中,就可能突发心脏
事件。
因此,天津中医药大学第一附属医院国务院特贴专家赵建国提醒,年过40岁,特别是有
心脏病高危因素的男性,应该随身携带急救药,为自己的心脏上 份"保险"。比如在皮包
或口袋里放一瓶硝酸甘油,经常停留的床头、书房、办公室、卫生间等也要预备一瓶。
一旦发生状况,立即取出一片放在舌下含服。服后疼 痛症状还没明显减轻,则可能是心
肌梗死,必须马上去医院。
三号防线:在外吃饭少喝浓茶。
有人说,"男人有胃病,原因有两条,要么受上司的气,要么受老婆的气。"虽然是玩笑
,不过要想胃肠好,确实要减少生气、紧张、焦虑等不良情绪。此外,还不能给脆弱的
胃太多食物刺激。
男人在外应酬,妻子最好常提醒他们:少喝浓茶、烈酒、咖啡,也要少吃生冷、辛辣食
物,从而减少胃酸分泌。胃不好的男人还要少抽烟,因为其中的尼古丁也能刺激胃黏膜
,引起胃功能失调。
四号防线:早晚喝点小米粥。
男人的胃病,尤其是胃溃疡和胃癌的发病率高于女性。要想帮他们护好胃,三分治七分
养最重要。
中华医学会消化病学分会名誉主任委员、原北京大学第三医院消化内科主任林三仁教授
教男人一个"护胃顺口溜":每餐定时八分饱,蔬菜水果不可少,早晚喝点小米粥。此外,
细嚼慢咽,多吃软、烂、加工细的食物,也能减少胃肠的"工作量"。但糯米不易吸收,
要少吃。有消化道溃疡的人,也不要喝太多的牛奶。
五号防线:每顿只吃八分饱。
每年单位体检完,不少男性都会在自己的体检报告上看见"脂肪肝"三个字。调查显示,
我国三四十岁的男性中,1/4都患有脂肪肝。
哈尔滨医科大学附属第四医院消化内二科主任李滨教授告诉记者,脂肪肝大多由酒精中
毒和营养过剩引起。男人事业越做越大,大餐越吃越多,腰围与日 俱增,就"喂养"出了
脂肪肝。要想预防,没什么"特效药",最关键就是每顿吃到七八分饱,尤其是晚饭,千
万别撑着。不仅要少吃红肉、油炸食品和甜食,少喝 酒,主食也不能吃太多,因为馒头
米饭也能转化成脂肪,进入肝脏。
六号防线:每周三到五次慢跑。
"暴走妈妈"陈玉蓉就靠着每天走路10公里,甩掉了自己的重度脂肪肝。这一经验,可以
让很多男性借鉴。
北京大学第三医院运动医学研究所浦钧宗教授说,预防和治疗脂肪肝最有效的办法莫过
于运动。运动量可以由小渐大,每次至少坚持20分钟,每周3— 5次,中年体胖者可每周
5—7次。对于男性来说,最便利、经济的方法是:每分钟120步左右的中速步行、围着小
区花园慢跑、临睡前做几十个仰卧起坐、尽量 用骑自行车或步行代替开车或坐车.....
.当然,如果能坚持每周游一次泳或爬次山,能更快地消耗肝脏内多余的脂肪。
七号防线:多喝水不憋尿。
在很多男性看来,尿频、尿急、尿不尽和眼花、牙齿脱落一样,都是衰老的自然表现,
不用担心。
然而,中国工程院院士、中国医师协会泌尿外科医师分会会长郭应禄教授指出,50岁以
上男性出现这些症状,往往意味着良性前列腺增生症。若不及时就医、治疗,可能会出
现尿潴留、反复血尿、泌尿系统感染,甚至诱发肾积水。要想避免前列腺出现"故障",
最好的方法就是多喝水,每天要喝2000— 2500毫升;不憋尿;多放松,保持心情愉快;洗
温水澡,缓解肌肉与前列腺紧张。
八号防线:白酒不能超一两。
当男人在酒精的作用下满脸红晕时,可能没想到,除了伤肝外,他的前列腺也跟着"醉"
了。
卫生部北京医院泌尿男科主任邓庶民指出,前列腺对酒精十分敏感,在酒精刺激下会变
得肥大、"笨拙",喝酒过量还会干扰性反应,减少性兴奋及性高 潮。他提醒,有轻微前
列腺炎的人,对任何刺激性的饮料和食物都要非常注意。喝白酒绝不能超过一两,咖啡
每天别超过一杯,还要少吃辛辣食物。
对男人来说,一下子做到上述八点确实很难,但为了自身健康和家庭幸福,还是一点点
做出改变吧。
avatar
s*k
2
今天电话里被人问晕了, 真没用别的啊。。。
avatar
w*n
3
恩,记住了,不喝酒,不抽烟,不喝咖啡,不喝浓茶, 多喝水,不憋尿
avatar
w*z
4
SOAP message 太烦杂, rest 用HTTP 的verb 直白。

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
y*u
5
偶像一句话说的很有道理
拿rest vs rpc有啥优势呢?

【在 w**z 的大作中提到】
: SOAP message 太烦杂, rest 用HTTP 的verb 直白。
avatar
b*c
6
flexibility
avatar
g*g
7
lightweight, human readable.

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
g*g
8
human readable, pass firewall.

【在 y**********u 的大作中提到】
: 偶像一句话说的很有道理
: 拿rest vs rpc有啥优势呢?

avatar
s*r
10
支持json

【在 w**z 的大作中提到】
: SOAP message 太烦杂, rest 用HTTP 的verb 直白。
avatar
l*a
11
上网查查吧。
SOAP是协议,client/server需要按照同样的格式实现。
REST的话,server那端实现standard interface, client side调用即可

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
o*g
12
都是协议

【在 l*****a 的大作中提到】
: 上网查查吧。
: SOAP是协议,client/server需要按照同样的格式实现。
: REST的话,server那端实现standard interface, client side调用即可

avatar
l*a
13
你再查查。。

【在 o***g 的大作中提到】
: 都是协议
avatar
s*r
14
WSDL,soap太heavy,需要严格按照schema进行造作,过程也不明朗,但保守死板的金
融行业都是soap
rest简单很多,不需要定义schema,开发测试都极其容易,一个curl解决全部问题,
json又很适合移动设备的通信,不火都难

【在 o***g 的大作中提到】
: 都是协议
avatar
z*3
15
rest是架构,主要特征是传输协议用的是http
soap是封装协议
严格说来两个并不互相冲突
但是rest可以用json这些,soap就只能用xml了
rest一般传输协议用http,soap就什么都可以

【在 o***g 的大作中提到】
: 都是协议
avatar
z*3
16
还有ws一般垮平台,对语言实现不敏感,一般rpc就是针对某种特定语言了
socket又太底层了,corba又太复杂了,所以各种trade off下来,还是ws吧

【在 g*****g 的大作中提到】
: human readable, pass firewall.
avatar
b*m
17
俺现在做的东东就是REST,确实好用。
avatar
p*2
18
不错 比Google领先一部步

【在 b***m 的大作中提到】
: 俺现在做的东东就是REST,确实好用。
avatar
b*m
19
都是工具罢了,呵呵。

【在 p*****2 的大作中提到】
: 不错 比Google领先一部步
avatar
y*u
20
我做了2年的Rest Migration.

【在 p*****2 的大作中提到】
: 不错 比Google领先一部步
avatar
p*n
21
Stateless!
avatar
b*m
22
嗯,stateless是个非常大的优点。

【在 p*********n 的大作中提到】
: Stateless!
avatar
g*g
23
Both rest and soap are stateless. http is stateless to begin with.

【在 b***m 的大作中提到】
: 嗯,stateless是个非常大的优点。
avatar
i*e
24
楼上的理解都比较肤浅,而且google有pass平台怎么可能被人领先,他发布的rest很好
。基于soap的ws比较常见于soa领域,而且支持复杂跨平台事务,这是rest所不具备的
,在soa领域rest很难做到复杂的api的自身描述,这也是soap的优势所在,rest更符合
网络精神,是因为他的stateless,rest在验证领域也有问题,不如soap支持的好,
soap有完整的signature支持协议,不过总的来说,各自在不同领域有优势,未来趋势
是rest,但是soap暂时有它的市场。
avatar
z*e
25
paas
google的cloud做得一般
soap封装起来太麻烦

【在 i*****e 的大作中提到】
: 楼上的理解都比较肤浅,而且google有pass平台怎么可能被人领先,他发布的rest很好
: 。基于soap的ws比较常见于soa领域,而且支持复杂跨平台事务,这是rest所不具备的
: ,在soa领域rest很难做到复杂的api的自身描述,这也是soap的优势所在,rest更符合
: 网络精神,是因为他的stateless,rest在验证领域也有问题,不如soap支持的好,
: soap有完整的signature支持协议,不过总的来说,各自在不同领域有优势,未来趋势
: 是rest,但是soap暂时有它的市场。

avatar
g*g
26
distributed transaction跟rest或者soap无关,两者要做都可以做到,而且做
distributed transaction需要三思是否必要。WS跟cloud
computing更是没什么大的相关度,google在云计算方面也远远落后于Amazon。
SOAP主要的优势是client端可以自动产生,因为WSDL定义了接口,相比之下REST基本上
只有wiki文档。
然而这个优势也随着REST工具的完善而减少。将来SOAP基本上成为legacy。REST的两大
优势,性能和可读性,是趋势。基于json的
rest在很长一堆时间会是主流,现在没有看到替代的技术。

【在 i*****e 的大作中提到】
: 楼上的理解都比较肤浅,而且google有pass平台怎么可能被人领先,他发布的rest很好
: 。基于soap的ws比较常见于soa领域,而且支持复杂跨平台事务,这是rest所不具备的
: ,在soa领域rest很难做到复杂的api的自身描述,这也是soap的优势所在,rest更符合
: 网络精神,是因为他的stateless,rest在验证领域也有问题,不如soap支持的好,
: soap有完整的signature支持协议,不过总的来说,各自在不同领域有优势,未来趋势
: 是rest,但是soap暂时有它的市场。

avatar
B*g
27
namespace烦死

【在 g*****g 的大作中提到】
: distributed transaction跟rest或者soap无关,两者要做都可以做到,而且做
: distributed transaction需要三思是否必要。WS跟cloud
: computing更是没什么大的相关度,google在云计算方面也远远落后于Amazon。
: SOAP主要的优势是client端可以自动产生,因为WSDL定义了接口,相比之下REST基本上
: 只有wiki文档。
: 然而这个优势也随着REST工具的完善而减少。将来SOAP基本上成为legacy。REST的两大
: 优势,性能和可读性,是趋势。基于json的
: rest在很长一堆时间会是主流,现在没有看到替代的技术。

avatar
c*3
28
soap vs. rest 就象c++ vs. shell script。各有各的用处,谁也取代不了谁。
都用soap,烦死。都用rest,累死。
avatar
s*k
29
这个能不能详细说说

【在 b***m 的大作中提到】
: 嗯,stateless是个非常大的优点。
avatar
b*m
30
这个我一言两语讲不清,因为我自己也是半瓶子水,不过基本任何一本REST的书开篇都
会讲到这个stateless的优势。REST还有一个很大的好处是容易被第三方audit。

【在 s********k 的大作中提到】
: 这个能不能详细说说
avatar
z*e
31
第三方验证是wsdl的优势所在,rest数据结构太自由,很难被audit

【在 b***m 的大作中提到】
: 这个我一言两语讲不清,因为我自己也是半瓶子水,不过基本任何一本REST的书开篇都
: 会讲到这个stateless的优势。REST还有一个很大的好处是容易被第三方audit。

avatar
b*c
32
stateless会不会被dos攻击
avatar
b*m
33
为啥书上说audit是REST的优势之一聂?

【在 z****e 的大作中提到】
: 第三方验证是wsdl的优势所在,rest数据结构太自由,很难被audit
avatar
l*a
34
负责审稿/校对的都不是专家
不过是小编一流
真正有第一手开发经验的都不会去审稿

【在 b***m 的大作中提到】
: 为啥书上说audit是REST的优势之一聂?
avatar
b*m
35
原来如彼。LOL

【在 l*****a 的大作中提到】
: 负责审稿/校对的都不是专家
: 不过是小编一流
: 真正有第一手开发经验的都不会去审稿

avatar
z*e
36
soap对于server之间的交流是比较重要的
有schema,错误会少很多,出错了,去查log对于海量数据来说
还是过于痛苦了,尤其是涉及到不同的团体之间的server
经常都不知道是哪里错了,这个时候用soap之类的会稳妥很多
很多行业的规范,都是xml
但是自身公司内部,那还是restful比较方便,开发快
公司之间的数据,xml比较靠谱,公司对个人,那就json就好了

【在 g*****g 的大作中提到】
: distributed transaction跟rest或者soap无关,两者要做都可以做到,而且做
: distributed transaction需要三思是否必要。WS跟cloud
: computing更是没什么大的相关度,google在云计算方面也远远落后于Amazon。
: SOAP主要的优势是client端可以自动产生,因为WSDL定义了接口,相比之下REST基本上
: 只有wiki文档。
: 然而这个优势也随着REST工具的完善而减少。将来SOAP基本上成为legacy。REST的两大
: 优势,性能和可读性,是趋势。基于json的
: rest在很长一堆时间会是主流,现在没有看到替代的技术。

avatar
b*m
37
嗯,我们就是公司内自己的东西,REST简单而且快。

【在 z****e 的大作中提到】
: soap对于server之间的交流是比较重要的
: 有schema,错误会少很多,出错了,去查log对于海量数据来说
: 还是过于痛苦了,尤其是涉及到不同的团体之间的server
: 经常都不知道是哪里错了,这个时候用soap之类的会稳妥很多
: 很多行业的规范,都是xml
: 但是自身公司内部,那还是restful比较方便,开发快
: 公司之间的数据,xml比较靠谱,公司对个人,那就json就好了

avatar
w*z
38
现在FB, AWS 的API 都是 rest 了。

【在 b***m 的大作中提到】
: 嗯,我们就是公司内自己的东西,REST简单而且快。
avatar
s*k
39
能详细展开说说?

【在 b*****c 的大作中提到】
: stateless会不会被dos攻击
avatar
r*s
40
SOAP/WS简单地说就是被一帮phd fucked up。本来很简单的请求/回复被这帮孙子搞出
各种花样出来cook paper毕业。你还辩不过这帮孙子,个个都振振有词。
最后有个充满幽默感的phd发表了一篇毕业论文,引进了RESTful(实际上是back to
basics), 结束了整个bullshit。大家都安静了,因为反对派终于手里有了同样的
theoretical junk弹药。
简单地说,restful就是你走到食堂的窗子前,敲敲窗,说你要买个包子,然后食堂给你
递个包子出来。
SOAP就是你走到食堂的窗子前,敲敲窗,递进去一个信封,大师傅得解开一个套一个的
信封,根据信封的内容,进行复杂的操作,信封都对上号了最后尼玛递给你一个包子,
信封只要错了一个大师傅就兜头浇你一勺汤。
你理解的没错,对买个包子来说,那就是有病。
avatar
s*k
41
如果光是复杂简单的区别,每个语言可以做一个专门针对SOAP的库什么的,也应该还好啊

【在 w**z 的大作中提到】
: SOAP message 太烦杂, rest 用HTTP 的verb 直白。
avatar
b*m
42
LOL

【在 r****s 的大作中提到】
: SOAP/WS简单地说就是被一帮phd fucked up。本来很简单的请求/回复被这帮孙子搞出
: 各种花样出来cook paper毕业。你还辩不过这帮孙子,个个都振振有词。
: 最后有个充满幽默感的phd发表了一篇毕业论文,引进了RESTful(实际上是back to
: basics), 结束了整个bullshit。大家都安静了,因为反对派终于手里有了同样的
: theoretical junk弹药。
: 简单地说,restful就是你走到食堂的窗子前,敲敲窗,说你要买个包子,然后食堂给你
: 递个包子出来。
: SOAP就是你走到食堂的窗子前,敲敲窗,递进去一个信封,大师傅得解开一个套一个的
: 信封,根据信封的内容,进行复杂的操作,信封都对上号了最后尼玛递给你一个包子,
: 信封只要错了一个大师傅就兜头浇你一勺汤。

avatar
s*k
43
这个我一直理解不太到位,能举一个保存state的协议以及其坏处吗?

【在 b***m 的大作中提到】
: 嗯,stateless是个非常大的优点。
avatar
s*k
44
另外高人们举个例子说说state transfer是怎么回事,就像比如在server端就是一个
JSON,在client端可以被transfer成不同表达形式?

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
r*s
45
他们说的stateless的优点是不是指可以随意load balance到任何一台server?
avatar
z*e
47
可以这么理解
不过我觉得说ws是stateless也有些问题
很多文档教怎么实现stateful的ws

【在 r****s 的大作中提到】
: 他们说的stateless的优点是不是指可以随意load balance到任何一台server?
avatar
z*e
48
状态有很多种
需要具体定义到底是哪一种状态?
scope可以是application, session, cluster
而且无状态放到其他层面也可能是有状态的
比如stateless ejb放在网络层面看,就是有状态的
rmi一般被认为是有状态的协议
http也不是完全无状态,http1是无状态
但是http2是有状态的,有无状态要看具体实现
网络不同层也有不同的有/无状态
比如http过去是无状态的,但是http用的tcp是有状态的
无状态的是udp
avatar
r*s
49
stateful不可以scaleout,比如在Amazon在tomcat你就不可以做sticky session,你如
果想scale out就要想办法把session过程的数据存在一个什么cache里面。这样就简化
request/response,把逻辑和数据放在middleware。那么request/response就无所谓
stateful了。
把session过程的数据放在request里面是傻逼,这帮孙子装傻还搞些什么教程出来,主
要是为了cook paper毕业。所以stateful ws是傻逼。
WS/SOAP/EJB被所有具有正常思维的程序员唾弃,是有其自身原因的。
avatar
s*k
50
具体能讲讲这个state包括哪些state?

【在 r****s 的大作中提到】
: stateful不可以scaleout,比如在Amazon在tomcat你就不可以做sticky session,你如
: 果想scale out就要想办法把session过程的数据存在一个什么cache里面。这样就简化
: request/response,把逻辑和数据放在middleware。那么request/response就无所谓
: stateful了。
: 把session过程的数据放在request里面是傻逼,这帮孙子装傻还搞些什么教程出来,主
: 要是为了cook paper毕业。所以stateful ws是傻逼。
: WS/SOAP/EJB被所有具有正常思维的程序员唾弃,是有其自身原因的。

avatar
r*s
51
在Amazon买过东西吗?checkout一下不就知道了?

【在 s********k 的大作中提到】
: 具体能讲讲这个state包括哪些state?
avatar
s*k
52
什么意思?amazon买东西的state都保存的吧,amazon都没有用restful?

【在 r****s 的大作中提到】
: 在Amazon买过东西吗?checkout一下不就知道了?
avatar
r*s
53
你问有什么state,那么Amazon checkout就有若干state。
如果Amazon买东西的state都保存,那就是一个不用ws的stateful的例子,而且是典型
例子。不然如果你啥都放在ws request里面,你在desktop上买了东西,到ipad上一查
卧槽东西都没了,那这个design就很失败,对不对?
主题是说明ws的stateful就是扯淡。Restful是另外的话题。
avatar
g*g
54
There are too many misconceptions in this thread. Stateful or stateless is
not the difference between SOAP and REST. Most people use either in
stateless way. SOAP provides some support in the spec for stateful requests.
But nothing stops you from building your custom plumbing in REST service
for stateful requests/responses.
Overall, stateful is an anti-pattern for scalability, but it's not the
reason you choose REST over SOAP. Because SOAP is usually stateless too.
avatar
z*e
55
re
主要还是协议和格式上的差异

requests.

【在 g*****g 的大作中提到】
: There are too many misconceptions in this thread. Stateful or stateless is
: not the difference between SOAP and REST. Most people use either in
: stateless way. SOAP provides some support in the spec for stateful requests.
: But nothing stops you from building your custom plumbing in REST service
: for stateful requests/responses.
: Overall, stateful is an anti-pattern for scalability, but it's not the
: reason you choose REST over SOAP. Because SOAP is usually stateless too.

avatar
s*k
56
好虫,按照你们netflix也是保存state的吧,比如问我在电脑上看得手机上可以接着看
,这个按你说法就不容易scale out,netflix怎么做的?

requests.

【在 g*****g 的大作中提到】
: There are too many misconceptions in this thread. Stateful or stateless is
: not the difference between SOAP and REST. Most people use either in
: stateless way. SOAP provides some support in the spec for stateful requests.
: But nothing stops you from building your custom plumbing in REST service
: for stateful requests/responses.
: Overall, stateful is an anti-pattern for scalability, but it's not the
: reason you choose REST over SOAP. Because SOAP is usually stateless too.

avatar
w*z
57
我听说是存在Cassandra里,好像几秒存一下。

【在 s********k 的大作中提到】
: 好虫,按照你们netflix也是保存state的吧,比如问我在电脑上看得手机上可以接着看
: ,这个按你说法就不容易scale out,netflix怎么做的?
:
: requests.

avatar
z*e
58
lol
wwzz你这么一说,stateful scale out的思路就出来了
前面话说得太死了点,只能说stateful相对不那么容易scale out
吃更多的资源,对比stateless而言,所以一般能stateless都stateless
省内存同时也降低耦合,但是要scale out也还是能够scale out
关键在于c*和hbase的不同,用hbase就很难

【在 w**z 的大作中提到】
: 我听说是存在Cassandra里,好像几秒存一下。
avatar
g*g
59
Netflix is not a good example, a client operation is limited to himself (
doesn't need to be visible for other users), losing some states are OK (like
last navigated position doesn't need to be kept), thus can be kept on
client side. There're lots of leeways in it. Saving session on selected
events in a C* DB is good enough.
For applications like real time Tweet, it's much more difficult.

【在 s********k 的大作中提到】
: 好虫,按照你们netflix也是保存state的吧,比如问我在电脑上看得手机上可以接着看
: ,这个按你说法就不容易scale out,netflix怎么做的?
:
: requests.

avatar
c*f
60
SOAP就是over engineering的产物
restful直白简单 容易理解 所有都通过HTTP协议
SOAP要走XML
avatar
r*s
61
这么简单的问题有啥好讨论的,我老早就指出了stateful不能在request里面干。

【在 r****s 的大作中提到】
: stateful不可以scaleout,比如在Amazon在tomcat你就不可以做sticky session,你如
: 果想scale out就要想办法把session过程的数据存在一个什么cache里面。这样就简化
: request/response,把逻辑和数据放在middleware。那么request/response就无所谓
: stateful了。
: 把session过程的数据放在request里面是傻逼,这帮孙子装傻还搞些什么教程出来,主
: 要是为了cook paper毕业。所以stateful ws是傻逼。
: WS/SOAP/EJB被所有具有正常思维的程序员唾弃,是有其自身原因的。

avatar
s*n
62
ejb里还有2/3 是stateless的. 怎么躺着就中枪了.

【在 r****s 的大作中提到】
: stateful不可以scaleout,比如在Amazon在tomcat你就不可以做sticky session,你如
: 果想scale out就要想办法把session过程的数据存在一个什么cache里面。这样就简化
: request/response,把逻辑和数据放在middleware。那么request/response就无所谓
: stateful了。
: 把session过程的数据放在request里面是傻逼,这帮孙子装傻还搞些什么教程出来,主
: 要是为了cook paper毕业。所以stateful ws是傻逼。
: WS/SOAP/EJB被所有具有正常思维的程序员唾弃,是有其自身原因的。

avatar
s*n
63
有一点rest可以完败soap的, cache
server前面弄个cache.设计好读写.
get类型的call可以直接用cache, server都不用处理.

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
r*s
64
what kind of idiot still uses ejb these days?

【在 s*******n 的大作中提到】
: ejb里还有2/3 是stateless的. 怎么躺着就中枪了.
avatar
z*3
65
ft
soap一样用http,甚至还可以用tcp或者udp
效率比http更高

【在 c****f 的大作中提到】
: SOAP就是over engineering的产物
: restful直白简单 容易理解 所有都通过HTTP协议
: SOAP要走XML

avatar
z*3
66
ft
soap一样用get,把soap放在http body里面
剩下的跟rest一样做,rest跟soap无本质冲突
rest可以用soap,soap一样可以用rest
两个都不是一个东西

【在 s*******n 的大作中提到】
: 有一点rest可以完败soap的, cache
: server前面弄个cache.设计好读写.
: get类型的call可以直接用cache, server都不用处理.

avatar
z*3
67
twitter加多redis之类的数据库多做点缓存就好了
但是同时也要弱化状态,尤其是singleton要替换stateless
twitter主要是量太大,相比之下每一次请求的处理反而并不复杂
这个在通信行业比如erlang有不少经验可以借鉴
比如lyce替换lamp构架,效率马上就爬五六倍上去
而且twitter平均每次处理的复杂度远没有ebiz要求高
ebiz还要卷入transaction,光c*还不够
要上db,两个都不太容易做
但是两个是不同类型的需求,不能一概而论
twitter那种不用ws,连rest都不用应该是最理想的
rest的http有不少限制,对于传输协议的限制甚至强过xml对于文件格式的限制
http毕竟只是一个超文本传输协议,而twitter那种压根就不是超文本
就是一破文本,rest都over kill了

like

【在 g*****g 的大作中提到】
: Netflix is not a good example, a client operation is limited to himself (
: doesn't need to be visible for other users), losing some states are OK (like
: last navigated position doesn't need to be kept), thus can be kept on
: client side. There're lots of leeways in it. Saving session on selected
: events in a C* DB is good enough.
: For applications like real time Tweet, it's much more difficult.

avatar
s*n
68
http GET 能放body? 这连电面都过不了.

两个都不是一个东西

【在 z*******3 的大作中提到】
: ft
: soap一样用get,把soap放在http body里面
: 剩下的跟rest一样做,rest跟soap无本质冲突
: rest可以用soap,soap一样可以用rest
: 两个都不是一个东西

avatar
z*e
69
ft
我说的是把soap放在http body里面
你确定你看懂了?

【在 s*******n 的大作中提到】
: http GET 能放body? 这连电面都过不了.
:
: 两个都不是一个东西

avatar
s*n
70
没看懂, 不过不重要,
干soap的, id什么的都在body里,你让cache server怎么知道cache entry staled
如果,id什么的都在url上了, 那基本上是 rest 了。

【在 z****e 的大作中提到】
: ft
: 我说的是把soap放在http body里面
: 你确定你看懂了?

avatar
b*r
71
REST vs SOAP
REST SOAP
Cached Yes over Get No due to POST
Transport protocol HTTP/HTTPS (currently tied to) Lots of like HTTP,
SMTP, etc.
Stateless Yes only Can support stateful
Stricter No Yes due to WSDL
XML Wrapper No (preferred in mobile devices) Yes
Message format XML, JSON, etc. XML
Misc More features such as security, reliable messaging, atomic
transaction
Architecture style Protocol

【在 s*******n 的大作中提到】
: 没看懂, 不过不重要,
: 干soap的, id什么的都在body里,你让cache server怎么知道cache entry staled
: 如果,id什么的都在url上了, 那基本上是 rest 了。

avatar
w*5
72
mark
avatar
g*r
73
super easy to scale

【在 s********k 的大作中提到】
: 这个能不能详细说说
avatar
j*f
74
这种问题很难回答,不同的人经历不同,答案也不一样。
如果你在实际应用中遇到过这个问题,你应该有答案。但是如果面试官的经历不同,那
你的答案对他来说可能是错的。
我最近做的一个项目中遇到过这个问题。 我是这样做的。
内部的各个节点之间通信用AMQP,因为对我来说这样更容易,而且可以做到实时。
对外部的API用REST,因为对于别人来说这个接口简单通用,容易使用,也易于控制。
简单来说,所用语言都提供了良好的支持。
在这里,API用REST的缺点就是实现实时比较困难。 比如,如果服务器端向客户端发送
实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现,但
是这样同时也失去了REST最重要的优点。
avatar
g*g
75
Web protocol is a pull protocol, it doesn't matter it's rest or soap, a
request cannot be initiated by server. That's one of the most important
reason web is safe.
However, long poll can be used to emulate push model, which has been
implemented in many libraries.

【在 j******f 的大作中提到】
: 这种问题很难回答,不同的人经历不同,答案也不一样。
: 如果你在实际应用中遇到过这个问题,你应该有答案。但是如果面试官的经历不同,那
: 你的答案对他来说可能是错的。
: 我最近做的一个项目中遇到过这个问题。 我是这样做的。
: 内部的各个节点之间通信用AMQP,因为对我来说这样更容易,而且可以做到实时。
: 对外部的API用REST,因为对于别人来说这个接口简单通用,容易使用,也易于控制。
: 简单来说,所用语言都提供了良好的支持。
: 在这里,API用REST的缺点就是实现实时比较困难。 比如,如果服务器端向客户端发送
: 实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现,但
: 是这样同时也失去了REST最重要的优点。

avatar
a*o
76
俺楼爬玩了,发现怎么大家都故意忽略了soap的多种传输协议支持呢?
avatar
l*9
77
mark
avatar
m*k
78
>>在这里,API用REST的缺点就是实现实时比较困难。 比如,如果服务器端向客户端发
送实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现,但
是这样同时也失去了REST最重要的优点。
这本来就不是ws的出发点吧
avatar
j*f
79
双向通信是ws重要特点之一

,但

【在 m*****k 的大作中提到】
: >>在这里,API用REST的缺点就是实现实时比较困难。 比如,如果服务器端向客户端发
: 送实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现,但
: 是这样同时也失去了REST最重要的优点。
: 这本来就不是ws的出发点吧

avatar
b*1
80
最近刚接触RESTful API,一头雾水,请教有什么书,视频,项目可以推荐吗?
万分感激!
avatar
e*c
81
REST是Roy Fielding在UCI的PhD论文。这哥们90年代写了很多HTTP的协议(RFC)。
SOAP是基于Web的Remote Procedure Call, 起了个好名字叫Web Service。 REST是
Paradigm,就像IoC(Inversion Of Control), 把WEB当作资源,每个都资源都有
CRUD四种操作。
avatar
y*e
82
mark, 准备design的好材料
avatar
e*3
83
我觉得Client side framework(Backbone, Ember, Angular) 对Rest流行也有一定推动
作用。Server side rest按convention来,client side define model object,然后
CRUD就自动实现了。

【在 s*****r 的大作中提到】
: WSDL,soap太heavy,需要严格按照schema进行造作,过程也不明朗,但保守死板的金
: 融行业都是soap
: rest简单很多,不需要定义schema,开发测试都极其容易,一个curl解决全部问题,
: json又很适合移动设备的通信,不火都难

avatar
c*e
84
mark
avatar
c*n
85
其实都扯淡, 只不过是一个 encoding,encapsulation 的问题。
用avro thrift protobuf 之类的idl 写出逻辑的interface, 想compile 出什么样的on
wire protocol 都可以(json XML. binary )
所以 goog 内部根本不屌什么 rest.
rest ,横行完全是因为历史原因:soap 做出来了, 但是tool chain 很烂, 搞得人去
写机器该做的事,不堪其苦。 有些程序员就说, 啊算了我写个简单的吧, 其实他还
是解决问题的方向错了, 该去让工具更强大而不是让product 更crudep

【在 s********k 的大作中提到】
: 今天电话里被人问晕了, 真没用别的啊。。。
avatar
g*g
86
Protobuf thrift can be compared to JSON and XML, not REST or SOAP. I think
you are comparing apple to orange. Also JSON dominates because it's readable
, can't say the same thing for binary protocol. For most apps, the small
performance gain is not worth it.

on

【在 c******n 的大作中提到】
: 其实都扯淡, 只不过是一个 encoding,encapsulation 的问题。
: 用avro thrift protobuf 之类的idl 写出逻辑的interface, 想compile 出什么样的on
: wire protocol 都可以(json XML. binary )
: 所以 goog 内部根本不屌什么 rest.
: rest ,横行完全是因为历史原因:soap 做出来了, 但是tool chain 很烂, 搞得人去
: 写机器该做的事,不堪其苦。 有些程序员就说, 啊算了我写个简单的吧, 其实他还
: 是解决问题的方向错了, 该去让工具更强大而不是让product 更crudep

avatar
c*n
87
protobuf. avro thrift all come naturally with a RPC generation framework
RPC ( including soap rest) are really nothing more than object encapsulation
, just on wire, not on disk.
plus these specially designed encapsulation mechanisms are so much more
advanced, for example allowing schema evolution ( API changes) without
efforts by application developers

readable

【在 g*****g 的大作中提到】
: Protobuf thrift can be compared to JSON and XML, not REST or SOAP. I think
: you are comparing apple to orange. Also JSON dominates because it's readable
: , can't say the same thing for binary protocol. For most apps, the small
: performance gain is not worth it.
:
: on

avatar
c*n
88
I don't care about actual on wire format , be it binary or JSON.
for debugging/Dev purposes, the format can be easily swapped/ interpreted
with the tools provided in these projects.
essentially the original proponents of rest were trying to write assembly
code, while we really need to be using high level Lang a and use tools to
compile

readable

【在 g*****g 的大作中提到】
: Protobuf thrift can be compared to JSON and XML, not REST or SOAP. I think
: you are comparing apple to orange. Also JSON dominates because it's readable
: , can't say the same thing for binary protocol. For most apps, the small
: performance gain is not worth it.
:
: on

avatar
w*z
89
the maintenance and evolution of thrift bases system is pita. in general
people are moving away from it.

encapsulation

【在 c******n 的大作中提到】
: protobuf. avro thrift all come naturally with a RPC generation framework
: RPC ( including soap rest) are really nothing more than object encapsulation
: , just on wire, not on disk.
: plus these specially designed encapsulation mechanisms are so much more
: advanced, for example allowing schema evolution ( API changes) without
: efforts by application developers
:
: readable

avatar
d*6
90
本末倒置了吧,是因为REST流行了这些framework才冒出来

【在 e*****3 的大作中提到】
: 我觉得Client side framework(Backbone, Ember, Angular) 对Rest流行也有一定推动
: 作用。Server side rest按convention来,client side define model object,然后
: CRUD就自动实现了。

avatar
g*g
91
Everything sounds easy, until it's not. You can't read binary so you need a
tool to convert back/forth, EVERY time on debugging. It's an undeniable
development overhead.
On a rainy day your upstream system put in a breaking change, with JSON you
know what's broken and you may make a simple tweak to solve the problem.
With Protobuf you are in the dark since it's not self-describing.
IMHO, it's fine to replace JSON with Protobuf where performance gain is
important. But starting with Protobuf everywhere is a premature optimization.

【在 c******n 的大作中提到】
: I don't care about actual on wire format , be it binary or JSON.
: for debugging/Dev purposes, the format can be easily swapped/ interpreted
: with the tools provided in these projects.
: essentially the original proponents of rest were trying to write assembly
: code, while we really need to be using high level Lang a and use tools to
: compile
:
: readable

avatar
c*n
92
I really don't think it's anything beyond trivial , it's just an extra pipe
command.
most of the cases it's just unwillingness to spend that extra 10minutes to
get familiar with the right tool and be done with it.
but I completely agree with u that when people talk about "performance" in
online app context, 90% of the time they don't really need it as much as
they claim, and readability/maintainability is much more important

a
you
optimization.

【在 g*****g 的大作中提到】
: Everything sounds easy, until it's not. You can't read binary so you need a
: tool to convert back/forth, EVERY time on debugging. It's an undeniable
: development overhead.
: On a rainy day your upstream system put in a breaking change, with JSON you
: know what's broken and you may make a simple tweak to solve the problem.
: With Protobuf you are in the dark since it's not self-describing.
: IMHO, it's fine to replace JSON with Protobuf where performance gain is
: important. But starting with Protobuf everywhere is a premature optimization.

avatar
j*3
93
我以为是我去年发的帖子的呢
avatar
c*n
94
really? I hate arguing over tech choices, but what u brought up is a very
big and general claim.
for the cpntrary, I only know a few anecdotal cases, for example. Cassandra
has been using thrift since day one ,both on internal and client protocols,
and Netflix uses Cassandra heavily, among many companies

【在 w**z 的大作中提到】
: the maintenance and evolution of thrift bases system is pita. in general
: people are moving away from it.
:
: encapsulation

avatar
g*g
95
Thrift has been replaced with a native protocol in C*.

Cassandra
,

【在 c******n 的大作中提到】
: really? I hate arguing over tech choices, but what u brought up is a very
: big and general claim.
: for the cpntrary, I only know a few anecdotal cases, for example. Cassandra
: has been using thrift since day one ,both on internal and client protocols,
: and Netflix uses Cassandra heavily, among many companies

avatar
g*g
96
You are still not getting the point. Protobuf doesn't compare to REST. You
often run protobuf in REST, as an XML/JSON replacement.

encapsulation

【在 c******n 的大作中提到】
: protobuf. avro thrift all come naturally with a RPC generation framework
: RPC ( including soap rest) are really nothing more than object encapsulation
: , just on wire, not on disk.
: plus these specially designed encapsulation mechanisms are so much more
: advanced, for example allowing schema evolution ( API changes) without
: efforts by application developers
:
: readable

avatar
c*n
97
it's u that's not getting it.
of course u can just use protobuf just as an envolope, in that sense it's
parallel to XML JSON.
but protobuf thrift avro all come with an RPC server , which gives u a sever
equivalent to http server + rest
I don't know why u keep arguing on this cuz the simplest way to see it is to
look at the documentation , which simply says that they provide an RPC
server,(apart from encapsulating)

【在 g*****g 的大作中提到】
: You are still not getting the point. Protobuf doesn't compare to REST. You
: often run protobuf in REST, as an XML/JSON replacement.
:
: encapsulation

avatar
g*g
98
You are making no sense, Protobuf is a protocol. There's no such thing as
standard RPC server, as that can't be language neutral. The document says
"If you want to use your message types with an RPC (Remote Procedure Call)
system, you can define an RPC service interface in a .proto file and the
protocol buffer compiler will generate service interface code and stubs in
your chosen language. "
You don't have to use http as underlying delivery for Protobuf, so does JSON
and XML just in case you don't know.

sever
to

【在 c******n 的大作中提到】
: it's u that's not getting it.
: of course u can just use protobuf just as an envolope, in that sense it's
: parallel to XML JSON.
: but protobuf thrift avro all come with an RPC server , which gives u a sever
: equivalent to http server + rest
: I don't know why u keep arguing on this cuz the simplest way to see it is to
: look at the documentation , which simply says that they provide an RPC
: server,(apart from encapsulating)

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。