RPC or noRPC,这是个问题

功能上来讲本质上有确实也没有什么区别的呀,举例Mina和netty或者自己写nio本质上也没有什么区别.只是实现方式不一样.我在前面的帖子中也说明了我的观点,我们有时候不是只需要考虑功能是否能实现就可以了,实现功能只是基本要求



文章的题目不是用哪个RPC,而是是否用RPC,但是你的回答也表明了你的观点.

这个问题...个人觉得已经不是啥问题。
比如你要提供一个服务S给应用A使用，那么其实你的服务S可以包装成S-RPC,S-REST,S-WS。。。。

这个问题不是使用什么RPC,而是是否使用RPC,但是你的回答也表明了你的观点.

我觉得还是看应用的具体需求，比如在同构系统中，并且是非工业级的系统中，RPC应该是首选。
在异构系统中，对实时性要求高的，不能使用HTTP协议的，应该用noRPC。比如我们作电力系统实时监控中，通讯协议都是有标准的，只能自己作TCP/IP通讯

我也同意使用RPC方式，这种方式实际上可以更好的降低系统耦合性，业务模块在不需要重新编写的情况下，就可以替换成不同的RPC方式发布，而如果用非RPC传参方式，就没有这么方便了。而且的RPC包对跨平台跨语言支持的也很好，比如PHPRPC、Hprose等，所以完全可以提到原始的低效的非RPC方式。

没实际应用过REST就不谈REST了.

而你说的那种RPC,我也不是很赞同,我还是更推崇接口传递简单格式化对象.如json或xml.在涉及到要和别人的系统联动时,这种语言无关的特性经常会让你感动的内牛满面.自然bean2xml/json或xml/json2bean的工作很繁琐,但是都可以通过工具减负.当然了,性能差了些.

无废话，偏向于RPC。
当然，为了不显示我偷懒，加一句“根据实际情况选择”。

推荐用REST方式。 你们的系统不可能一直不变,以后有可能扩展,也有可能和其他公司结合.用PRC跨语言费劲，尤其是你们这边是java写的

LZ说的区别:1.A-Y的代码功能相同,既然相同就不应该有这么多的重复应用。如果是在说解析数据的代码的话，这个代码实际上很少。
2.扩展时Z代码如果可以不修改老接口，那么用REST也一样可以，甚至更方便。
3.4.这两个是Z-提供者考虑的事情。

我猜测LZ实际上没做过NoPRC,所以才希望选择PRC的方式

PRC和REST比较
REST方式耦合度更低,扩展方便,跨语言。
PRC性能较好(但实际上意义不大，因为一般来说通信都不是性能瓶颈)。
如果Z应用和A-Y应用是同一小组开发的话，可以用PRC。否则还是REST的好。

就我所了解的,你这里说的REST其实就是soap或者其变种(载体为json)其实本质上还是是RPC.
REST所代表的是对架构的影响,是一种分解问题的新思路.而不只是体现在接口形式的简单和语言无关性上.

个人非常推荐PHPRPC.
这个不是PHP的RPC,
而是跨语言的RPC