s********k
发帖数: 2352 | |
w**z
发帖数: 8232 | 2 SOAP message 太烦杂， rest 用HTTP 的verb 直白。
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
y**********u
发帖数: 6366 | 3 偶像一句话说的很有道理
拿rest vs rpc有啥优势呢？
【在 w**z 的大作中提到】
: SOAP message 太烦杂， rest 用HTTP 的verb 直白。
|
b*****c
发帖数: 1103 | |
g*****g
发帖数: 34805 | 5 lightweight, human readable.
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
g*****g
发帖数: 34805 | 6 human readable, pass firewall.
【在 y**********u 的大作中提到】
: 偶像一句话说的很有道理
: 拿rest vs rpc有啥优势呢？
|
p*u
发帖数: 136 | 7 http://www.infoq.com/cn/articles/understanding-restful-style
理解本真的REST架构风格
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
s*****r
发帖数: 43070 | 8 支持json
【在 w**z 的大作中提到】
: SOAP message 太烦杂， rest 用HTTP 的verb 直白。
|
l*****a
发帖数: 14598 | 9 上网查查吧。
SOAP是协议，client/server需要按照同样的格式实现。
REST的话，server那端实现standard interface, client side调用即可
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
o***g
发帖数: 2784 | 10 都是协议
【在 l*****a 的大作中提到】
: 上网查查吧。
: SOAP是协议，client/server需要按照同样的格式实现。
: REST的话，server那端实现standard interface, client side调用即可
|
|
|
l*****a
发帖数: 14598 | 11 你再查查。。
【在 o***g 的大作中提到】
: 都是协议
|
s*****r
发帖数: 43070 | 12 WSDL，soap太heavy，需要严格按照schema进行造作，过程也不明朗，但保守死板的金
融行业都是soap
rest简单很多，不需要定义schema，开发测试都极其容易，一个curl解决全部问题，
json又很适合移动设备的通信，不火都难
【在 o***g 的大作中提到】
: 都是协议
|
z*******3
发帖数: 13709 | 13 rest是架构，主要特征是传输协议用的是http
soap是封装协议
严格说来两个并不互相冲突
但是rest可以用json这些，soap就只能用xml了
rest一般传输协议用http，soap就什么都可以
【在 o***g 的大作中提到】
: 都是协议
|
z*******3
发帖数: 13709 | 14 还有ws一般垮平台，对语言实现不敏感，一般rpc就是针对某种特定语言了
socket又太底层了，corba又太复杂了，所以各种trade off下来，还是ws吧
【在 g*****g 的大作中提到】
: human readable, pass firewall.
|
b***m
发帖数: 5987 | |
p*****2
发帖数: 21240 | 16 不错 比Google领先一部步
【在 b***m 的大作中提到】
: 俺现在做的东东就是REST，确实好用。
|
b***m
发帖数: 5987 | 17 都是工具罢了，呵呵。
【在 p*****2 的大作中提到】
: 不错 比Google领先一部步
|
y**********u
发帖数: 6366 | 18 我做了2年的Rest Migration.
【在 p*****2 的大作中提到】
: 不错 比Google领先一部步
|
p*********n
发帖数: 10 | |
b***m
发帖数: 5987 | 20 嗯，stateless是个非常大的优点。
【在 p*********n 的大作中提到】
: Stateless!
|
|
|
g*****g
发帖数: 34805 | 21 Both rest and soap are stateless. http is stateless to begin with.
【在 b***m 的大作中提到】
: 嗯，stateless是个非常大的优点。
|
i*****e
发帖数: 20 | 22 楼上的理解都比较肤浅，而且google有pass平台怎么可能被人领先，他发布的rest很好
。基于soap的ws比较常见于soa领域，而且支持复杂跨平台事务，这是rest所不具备的
，在soa领域rest很难做到复杂的api的自身描述，这也是soap的优势所在，rest更符合
网络精神，是因为他的stateless，rest在验证领域也有问题，不如soap支持的好，
soap有完整的signature支持协议，不过总的来说，各自在不同领域有优势，未来趋势
是rest，但是soap暂时有它的市场。 |
z****e
发帖数: 54598 | 23 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暂时有它的市场。
|
g*****g
发帖数: 34805 | 24 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暂时有它的市场。
|
B*****g
发帖数: 34098 | 25 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在很长一堆时间会是主流，现在没有看到替代的技术。
|
c******3
发帖数: 296 | 26 soap vs. rest 就象c++ vs. shell script。各有各的用处，谁也取代不了谁。
都用soap，烦死。都用rest，累死。 |
s********k
发帖数: 2352 | 27 这个能不能详细说说
【在 b***m 的大作中提到】
: 嗯，stateless是个非常大的优点。
|
b***m
发帖数: 5987 | 28 这个我一言两语讲不清，因为我自己也是半瓶子水，不过基本任何一本REST的书开篇都
会讲到这个stateless的优势。REST还有一个很大的好处是容易被第三方audit。
【在 s********k 的大作中提到】
: 这个能不能详细说说
|
z****e
发帖数: 54598 | 29 第三方验证是wsdl的优势所在，rest数据结构太自由，很难被audit
【在 b***m 的大作中提到】
: 这个我一言两语讲不清，因为我自己也是半瓶子水，不过基本任何一本REST的书开篇都
: 会讲到这个stateless的优势。REST还有一个很大的好处是容易被第三方audit。
|
b*****c
发帖数: 1103 | |
|
|
b***m
发帖数: 5987 | 31 为啥书上说audit是REST的优势之一聂？
【在 z****e 的大作中提到】
: 第三方验证是wsdl的优势所在，rest数据结构太自由，很难被audit
|
l*****a
发帖数: 14598 | 32 负责审稿/校对的都不是专家
不过是小编一流
真正有第一手开发经验的都不会去审稿
【在 b***m 的大作中提到】
: 为啥书上说audit是REST的优势之一聂？
|
b***m
发帖数: 5987 | 33 原来如彼。LOL
【在 l*****a 的大作中提到】
: 负责审稿/校对的都不是专家
: 不过是小编一流
: 真正有第一手开发经验的都不会去审稿
|
z****e
发帖数: 54598 | 34 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在很长一堆时间会是主流，现在没有看到替代的技术。
|
b***m
发帖数: 5987 | 35 嗯，我们就是公司内自己的东西，REST简单而且快。
【在 z****e 的大作中提到】
: soap对于server之间的交流是比较重要的
: 有schema，错误会少很多，出错了，去查log对于海量数据来说
: 还是过于痛苦了，尤其是涉及到不同的团体之间的server
: 经常都不知道是哪里错了，这个时候用soap之类的会稳妥很多
: 很多行业的规范，都是xml
: 但是自身公司内部，那还是restful比较方便，开发快
: 公司之间的数据，xml比较靠谱，公司对个人，那就json就好了
|
w**z
发帖数: 8232 | 36 现在FB， AWS 的API 都是 rest 了。
【在 b***m 的大作中提到】
: 嗯，我们就是公司内自己的东西，REST简单而且快。
|
s********k
发帖数: 6180 | 37 能详细展开说说？
【在 b*****c 的大作中提到】
: stateless会不会被dos攻击
|
r****s
发帖数: 1025 | 38 SOAP/WS简单地说就是被一帮phd fucked up。本来很简单的请求/回复被这帮孙子搞出
各种花样出来cook paper毕业。你还辩不过这帮孙子，个个都振振有词。
最后有个充满幽默感的phd发表了一篇毕业论文，引进了RESTful（实际上是back to
basics), 结束了整个bullshit。大家都安静了，因为反对派终于手里有了同样的
theoretical junk弹药。
简单地说，restful就是你走到食堂的窗子前，敲敲窗，说你要买个包子,然后食堂给你
递个包子出来。
SOAP就是你走到食堂的窗子前，敲敲窗，递进去一个信封，大师傅得解开一个套一个的
信封，根据信封的内容，进行复杂的操作，信封都对上号了最后尼玛递给你一个包子，
信封只要错了一个大师傅就兜头浇你一勺汤。
你理解的没错，对买个包子来说，那就是有病。 |
s********k
发帖数: 6180 | 39 如果光是复杂简单的区别，每个语言可以做一个专门针对SOAP的库什么的，也应该还好啊
【在 w**z 的大作中提到】
: SOAP message 太烦杂， rest 用HTTP 的verb 直白。
|
b***m
发帖数: 5987 | 40 LOL
【在 r****s 的大作中提到】
: SOAP/WS简单地说就是被一帮phd fucked up。本来很简单的请求/回复被这帮孙子搞出
: 各种花样出来cook paper毕业。你还辩不过这帮孙子，个个都振振有词。
: 最后有个充满幽默感的phd发表了一篇毕业论文，引进了RESTful（实际上是back to
: basics), 结束了整个bullshit。大家都安静了，因为反对派终于手里有了同样的
: theoretical junk弹药。
: 简单地说，restful就是你走到食堂的窗子前，敲敲窗，说你要买个包子,然后食堂给你
: 递个包子出来。
: SOAP就是你走到食堂的窗子前，敲敲窗，递进去一个信封，大师傅得解开一个套一个的
: 信封，根据信封的内容，进行复杂的操作，信封都对上号了最后尼玛递给你一个包子，
: 信封只要错了一个大师傅就兜头浇你一勺汤。
|
|
|
s********k
发帖数: 6180 | 41 这个我一直理解不太到位，能举一个保存state的协议以及其坏处吗？
【在 b***m 的大作中提到】
: 嗯，stateless是个非常大的优点。
|
s********k
发帖数: 6180 | 42 另外高人们举个例子说说state transfer是怎么回事，就像比如在server端就是一个
JSON，在client端可以被transfer成不同表达形式？
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
r****s
发帖数: 1025 | 43 他们说的stateless的优点是不是指可以随意load balance到任何一台server? |
r****s
发帖数: 1025 | |
z****e
发帖数: 54598 | 45 可以这么理解
不过我觉得说ws是stateless也有些问题
很多文档教怎么实现stateful的ws
【在 r****s 的大作中提到】
: 他们说的stateless的优点是不是指可以随意load balance到任何一台server?
|
z****e
发帖数: 54598 | 46 状态有很多种
需要具体定义到底是哪一种状态？
scope可以是application, session, cluster
而且无状态放到其他层面也可能是有状态的
比如stateless ejb放在网络层面看，就是有状态的
rmi一般被认为是有状态的协议
http也不是完全无状态，http1是无状态
但是http2是有状态的，有无状态要看具体实现
网络不同层也有不同的有/无状态
比如http过去是无状态的，但是http用的tcp是有状态的
无状态的是udp |
r****s
发帖数: 1025 | 47 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被所有具有正常思维的程序员唾弃，是有其自身原因的。 |
s********k
发帖数: 6180 | 48 具体能讲讲这个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被所有具有正常思维的程序员唾弃，是有其自身原因的。
|
r****s
发帖数: 1025 | 49 在Amazon买过东西吗？checkout一下不就知道了？
【在 s********k 的大作中提到】
: 具体能讲讲这个state包括哪些state？
|
s********k
发帖数: 6180 | 50 什么意思？amazon买东西的state都保存的吧，amazon都没有用restful？
【在 r****s 的大作中提到】
: 在Amazon买过东西吗？checkout一下不就知道了？
|
|
|
r****s
发帖数: 1025 | 51 你问有什么state，那么Amazon checkout就有若干state。
如果Amazon买东西的state都保存，那就是一个不用ws的stateful的例子，而且是典型
例子。不然如果你啥都放在ws request里面，你在desktop上买了东西，到ipad上一查
卧槽东西都没了，那这个design就很失败，对不对？
主题是说明ws的stateful就是扯淡。Restful是另外的话题。 |
g*****g
发帖数: 34805 | 52 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. |
z****e
发帖数: 54598 | 53 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.
|
s********k
发帖数: 6180 | 54 好虫，按照你们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.
|
w**z
发帖数: 8232 | 55 我听说是存在Cassandra里，好像几秒存一下。
【在 s********k 的大作中提到】
: 好虫，按照你们netflix也是保存state的吧，比如问我在电脑上看得手机上可以接着看
: ，这个按你说法就不容易scale out，netflix怎么做的？
:
: requests.
|
z****e
发帖数: 54598 | 56 lol
wwzz你这么一说，stateful scale out的思路就出来了
前面话说得太死了点，只能说stateful相对不那么容易scale out
吃更多的资源，对比stateless而言，所以一般能stateless都stateless
省内存同时也降低耦合，但是要scale out也还是能够scale out
关键在于c*和hbase的不同，用hbase就很难
【在 w**z 的大作中提到】
: 我听说是存在Cassandra里，好像几秒存一下。
|
g*****g
发帖数: 34805 | 57 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.
|
c****f
发帖数: 1102 | 58 SOAP就是over engineering的产物
restful直白简单 容易理解 所有都通过HTTP协议
SOAP要走XML |
r****s
发帖数: 1025 | 59 这么简单的问题有啥好讨论的，我老早就指出了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被所有具有正常思维的程序员唾弃，是有其自身原因的。
|
s*******n
发帖数: 196 | 60 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被所有具有正常思维的程序员唾弃，是有其自身原因的。
|
|
|
s*******n
发帖数: 196 | 61 有一点rest可以完败soap的, cache
server前面弄个cache.设计好读写.
get类型的call可以直接用cache, server都不用处理.
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
r****s
发帖数: 1025 | 62 what kind of idiot still uses ejb these days?
【在 s*******n 的大作中提到】
: ejb里还有2/3 是stateless的. 怎么躺着就中枪了.
|
z*******3
发帖数: 13709 | 63 ft
soap一样用http，甚至还可以用tcp或者udp
效率比http更高
【在 c****f 的大作中提到】
: SOAP就是over engineering的产物
: restful直白简单 容易理解 所有都通过HTTP协议
: SOAP要走XML
|
z*******3
发帖数: 13709 | 64 ft
soap一样用get，把soap放在http body里面
剩下的跟rest一样做，rest跟soap无本质冲突
rest可以用soap，soap一样可以用rest
两个都不是一个东西
【在 s*******n 的大作中提到】
: 有一点rest可以完败soap的, cache
: server前面弄个cache.设计好读写.
: get类型的call可以直接用cache, server都不用处理.
|
z*******3
发帖数: 13709 | 65 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.
|
s*******n
发帖数: 196 | 66 http GET 能放body? 这连电面都过不了.
两个都不是一个东西
【在 z*******3 的大作中提到】
: ft
: soap一样用get，把soap放在http body里面
: 剩下的跟rest一样做，rest跟soap无本质冲突
: rest可以用soap，soap一样可以用rest
: 两个都不是一个东西
|
z****e
发帖数: 54598 | 67 ft
我说的是把soap放在http body里面
你确定你看懂了？
【在 s*******n 的大作中提到】
: http GET 能放body? 这连电面都过不了.
:
: 两个都不是一个东西
|
s*******n
发帖数: 196 | 68 没看懂， 不过不重要,
干soap的， id什么的都在body里，你让cache server怎么知道cache entry staled
如果，id什么的都在url上了， 那基本上是 rest 了。
【在 z****e 的大作中提到】
: ft
: 我说的是把soap放在http body里面
: 你确定你看懂了？
|
b********r
发帖数: 620 | 69 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 了。
|
w*****5
发帖数: 75 | |
|
|
g****r
发帖数: 1589 | 71 super easy to scale
【在 s********k 的大作中提到】
: 这个能不能详细说说
|
j******f
发帖数: 825 | 72 这种问题很难回答，不同的人经历不同，答案也不一样。
如果你在实际应用中遇到过这个问题，你应该有答案。但是如果面试官的经历不同，那
你的答案对他来说可能是错的。
我最近做的一个项目中遇到过这个问题。 我是这样做的。
内部的各个节点之间通信用AMQP，因为对我来说这样更容易，而且可以做到实时。
对外部的API用REST，因为对于别人来说这个接口简单通用，容易使用，也易于控制。
简单来说，所用语言都提供了良好的支持。
在这里，API用REST的缺点就是实现实时比较困难。 比如，如果服务器端向客户端发送
实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现，但
是这样同时也失去了REST最重要的优点。 |
g*****g
发帖数: 34805 | 73 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最重要的优点。
|
a***o
发帖数: 118 | 74 俺楼爬玩了，发现怎么大家都故意忽略了soap的多种传输协议支持呢？ |
l**********9
发帖数: 537 | |
m*****k
发帖数: 731 | 76 >>在这里，API用REST的缺点就是实现实时比较困难。 比如，如果服务器端向客户端发
送实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现，但
是这样同时也失去了REST最重要的优点。
这本来就不是ws的出发点吧 |
j******f
发帖数: 825 | 77 双向通信是ws重要特点之一
，但
【在 m*****k 的大作中提到】
: >>在这里，API用REST的缺点就是实现实时比较困难。 比如，如果服务器端向客户端发
: 送实时信息需要客户端不停的去polling才能实现。当然现在可以用第三方的库实现，但
: 是这样同时也失去了REST最重要的优点。
: 这本来就不是ws的出发点吧
|
b**********1
发帖数: 215 | 78 最近刚接触RESTful API,一头雾水，请教有什么书，视频，项目可以推荐吗？
万分感激！ |
e********c
发帖数: 66 | 79 REST是Roy Fielding在UCI的PhD论文。这哥们90年代写了很多HTTP的协议（RFC）。
SOAP是基于Web的Remote Procedure Call， 起了个好名字叫Web Service。 REST是
Paradigm，就像IoC（Inversion Of Control）， 把WEB当作资源，每个都资源都有
CRUD四种操作。 |
y*****e
发帖数: 712 | |
|
|
e*****3
发帖数: 610 | 81 我觉得Client side framework(Backbone, Ember, Angular) 对Rest流行也有一定推动
作用。Server side rest按convention来，client side define model object，然后
ＣＲＵＤ就自动实现了。
【在 s*****r 的大作中提到】
: WSDL，soap太heavy，需要严格按照schema进行造作，过程也不明朗，但保守死板的金
: 融行业都是soap
: rest简单很多，不需要定义schema，开发测试都极其容易，一个curl解决全部问题，
: json又很适合移动设备的通信，不火都难
|
c******e
发帖数: 558 | |
c******n
发帖数: 4965 | 83 其实都扯淡， 只不过是一个 encoding,encapsulation 的问题。
用avro thrift protobuf 之类的idl 写出逻辑的interface, 想compile 出什么样的on
wire protocol 都可以（json XML. binary )
所以 goog 内部根本不屌什么 rest.
rest ,横行完全是因为历史原因：soap 做出来了， 但是tool chain 很烂， 搞得人去
写机器该做的事，不堪其苦。 有些程序员就说， 啊算了我写个简单的吧， 其实他还
是解决问题的方向错了， 该去让工具更强大而不是让product 更crudep
【在 s********k 的大作中提到】
: 今天电话里被人问晕了， 真没用别的啊。。。
|
g*****g
发帖数: 34805 | 84 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
|
c******n
发帖数: 4965 | 85 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
|
c******n
发帖数: 4965 | 86 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
|
w**z
发帖数: 8232 | 87 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
|
d**********6
发帖数: 4434 | 88 本末倒置了吧，是因为REST流行了这些framework才冒出来
【在 e*****3 的大作中提到】
: 我觉得Client side framework(Backbone, Ember, Angular) 对Rest流行也有一定推动
: 作用。Server side rest按convention来，client side define model object，然后
: ＣＲＵＤ就自动实现了。
|
g*****g
发帖数: 34805 | 89 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
|
c******n
发帖数: 4965 | 90 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.
|
|
|
j**********3
发帖数: 3211 | |
c******n
发帖数: 4965 | 92 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
|
g*****g
发帖数: 34805 | 93 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
|
g*****g
发帖数: 34805 | 94 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
|
c******n
发帖数: 4965 | 95 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
|
g*****g
发帖数: 34805 | 96 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)
|
