消息？还是状态？

不管期望什么，服务计算的现实任务还是实现异构系统间的互操作。既然是为了互操作，两系统间总是要交换一些东西，那么这些交换的东西是消息呢？还是的状态？这便是SOAP(WS-*)和REST两个派别争执的核心。

在理想世界中， 消息和状态的变更是一回事情，只是视点不同。假如A按了B上的一个按钮，这便有了两个互补消息(e, e')，e使得系统B发生了状态变化，同理事件e'也使得系统A发生了变化。或许疑惑为何是两个互补的消息，不是一个吗？这也就想力有作用与反作用力，我推你一把，同样的力也反作用我自己。就服务范畴而言，消息e可以理解为请求，而消息e'理解为系统B处理事件e的响应。

再稍微复杂一点，假设A依次按了B的两个按钮。系统B因消息e由初始的s0变为s1，再因消息f变为s2； 系统A也相应地因消息e'由状态t0变为t1，再因消息f'变为t2。对于这两组互补消息(e, e')和(f, f')，很明显(e, e')发生于(f, f')之前。

至此，我理解发生顺序很重要，如果错乱，系统的状态肯定混乱。现实中总因素导致消息丢失，延时，因并发而冲突。这也就是为什么SOAP族的协议越做越复杂的一种因素。

尽管REST耦合性更为松弛，但你会发现，这种松弛令服务的自动发现和组合难以实现，还产生了令人恼火的资源发散，希望能够统一的处理，但这并不容易。