RPC or noRPC,这是个问题

需要很高的性能，模块之间耦合程度高就用RPC

不需要很高的性能，模块之间独立性强，就用REST

我选择选择RPC：
楼主提的缺点:
1.Z应用的开发者需要承担责任,如果client的Jar在线上出现bug,他们难辞其咎.(但这对A-Y的开发者来说是个优点)
2.如果jar包线上出bug,那么A-Y个应用都需要重启,并引入新的jar包.
3.不能满足一些人自以为是的欲望,因为有一些人一直觉得自己的代码是最好的,所以他们宁可重复造轮子.

第一点，Z应用是提供者当然有责任解决bug了，而且多了25个使用者，可以很好的覆盖所有的功能，加速功能的进化（根据开闭原则，对外部开放接口，封闭内部的实现细节）
第二点，这个看你怎么实现了，一般rpc出bug也只是你的服务端吧！应该客户端的jar修改基本上比教少！如果接口发生变动是不是可以利用classloader来动态装载新的jar来热部署！
第三点，既然是企业内部，那还不好说，重复的劳动要不得阿！或者内部开放你的rpc源代码，有冲动的人提出修改申请来冲动下也可以的！
^ ^

看看JE的风气, 这种讨论的帖子都被批成新手帖

继续投吧, 反正我是0

我对RPC和noRPC之间的界线比较模糊，比如说我们现在的应用，实际上就是通过url提供参数调用，可是server端还是给提供了一个jar包，对调用进行wrap，也就是客户端直接使用方法接口就可以，你说这算是RPC还是noRPC？

根据lz所描述的优缺点，我觉得lz的根本问题是不是要用server提供端的jar包的问题，至于c/s间如何通讯，那是另外一个问题。

对于我来讲，我倾向于使用提供包，因为这种方式所带来的唯一风险，就是提供的jar包的bug问题，其实不管哪种方式都有个双方协议的问题，不管是方法，还是参数格式。从这方面来看，只要接口不变，即使jar包出现bug，客户端重启一次又能带来多大问题呢。另外，对于服务器端的功能最熟悉的还是服务器端开发者，我想这个jar包出现bug的概率，比起客户端自己去编写要低多了。

你可以根据下面两个问题来衡量:
1.你需要自己考虑你的对象这么转换成bytes吗
2.你需要自己实现应用层协议吗

如果这样考虑的话，那就是属于使用哪种以及哪层通信协议，以及使用哪种通信格式的问题了。
定好这点后，接下来才是由server提供端来提供jar来隐藏通信格式，还是提供一个doc，由用户自己来编写。
当然根据通信协议以及格式的不同，客户端用户编写的难易也有所不同，另外还要考虑服务器端愿不愿意暴露那么多东西。

其实这个问题讨论起来也很复杂，我不知道lz站在哪个角度，或者从一个什么场景下考虑这个问题，如果不限定些东西的话，好像无法得出结论。
如果这样考虑的话，那就是属于使用哪种以及哪层通信协议，以及使用哪种通信格式的问题了。
定好这点后，接下来才是由server提供端来提供jar来隐藏通信格式，还是提供一个doc，由用户自己来编写。
当然根据通信协议以及格式的不同，客户端用户编写的难易也有所不同，另外还要考虑服务器端愿不愿意暴露那么多东西。

其实这个问题讨论起来也很复杂，我不知道lz站在哪个角度，或者从一个什么场景下考虑这个问题，如果不限定些东西的话，好像无法得出结论。