RPC or noRPC,这是个问题

webservice是个不错的选择，因为webservice是一个开放的事实标准

补充,rpc的方式,还有一个好处,参数的校验可以在client端完成, 在开发时期,这个优点可以节约很多沟通的成本,在运行时期,这个优点可以避免无谓的远程开销.

用Aｃｔｏｒ

如果外部系统的dev偷懒怎么办？
Server不做参数校验是不是完全把命运托付给别人了？
我觉得这个问题不是大问题，Server还是得做校验。
LZ的标题确实是有点歧义吧

学习phprpc中，有没有想过优化WebServices，而不是开创一个新的协议呢？推广的成本很高啊，www.phprpc.org还是中文版的，- -！！

协议实现跟普通程序本质上是一样的，都是“数据结构”+“算法”。

“好的数据结构“+“好的算法“肯定比“差的数据结构“+“差的算法“要好，这一点无庸置疑。

但是如果是”好的数据结构“+”差的算法“和”差的数据结构“+”好的算法“比起来，孰优孰劣呢？

在我看来”好的数据结构“+”差的算法“要远远好于”差的数据结构“+”好的算法“，为何这样说呢？

因为前者的算法还可以优化，只要数据结构不变，算法的优化在不会影响协议正常工作的情况下，可以让协议实现变得更优更好，直至达到“好的数据结构“+“好的算法“这样一个境界。

而后者在算法上已经没有改进的余地了，要想优化就需要修改数据结构，但数据结构一改，那协议也就变了，所以说后者已经达到了极限，已经没有可以继续进化的可能了。

而WebServices就是后者，WebServices的数据结构已经注定了它的低效，专家们在实现它的算法上也已经竭尽所能达到了它能达到的最高性能，再继续进步的可能性已经不大了。

所以只有重新开创一个新的从数据结构上就设计为最优的协议，才能保证日后能够进化为“好的数据结构“+“好的算法“这样一个实现。在WebService上改良是没有这个可能的啦。

当然这里我并没有说PHPRPC就是一个从数据结构上就是一个设计最优的协议，如果是这样的话，也就不会有现在的商业版的Hprose存在的必要了。

**你说的很有道理，我赞同你对“好的数据结构”的观点。

**但是我想设计那些xml传输格式的委员会不会不懂吧？
所以我觉得WebService设计的协议应该是有他的渊源的，“存在即合理”嘛
不知道andot学长有没有了解过那些渊源呢？不妨给大家讲讲吧。


我在google WS历史的时候，无意中看到一段颇富哲理的话：

一不小心，写得太多了，单独开了个帖子：SOAP和WebService那些事

删除本次发帖

提不提供客户端包，个人认为主要是个成本问题。
如果你是卖服务的，你当然要提供，而且要提供各种方式客户端包方便客户。
如果是合作，对方出钱就做，因为这些代码维护和升级都需要钱。
如果是一个企业内部多个系统，建议改改设计，如果确实要这么设计，两种做法：
1、基于信任的做法，分清责任和成本，可选择提供或不提供
2、基于不信任的做法，分清责任和成本，都不提供，只提供标准服务