个人对SOAP/Web Service和REST/OData的一些想法

[鸣鸣Amadues]

找了半天也没有合适的板块，最后还是决定发这里了，虽然估计也不大会有人气的样子：）

正文开始，模块化是程序开发的思想之一，即传入参数，传出结果，至于当中处理的过程调用者并不用关心。这种功能模块，以前叫函数，现在在面向对象里叫方法，当然也可以泛称为程序。

原本这些方法都是在同一个系统或开发环境里才能调用的，而Web Service的理念是通过网络让任意系统里的方法都可以被其他任意系统调用，比如我在我的项目里用.NET开发了一个方法，你可以在你的JAVA项目上调用我的方法，这种调用是跨平台和语言的。

想实现这种调用，需要的东西基本是被调用方的网址，类和方法的名字，接口参数等信息，然后按照一定的格式存放在XML里传输以供调用方解析，一般普遍都是通过HTTP的POST方法来传输这些数据。如果调用方是Web程序，那么直接写JS就可以了，如果调用方是客户端程序，那么先在客户端生成一个类，这个类的接口参数就是被调用方法的参数，这个类的“背后”应该是一个类似于代理服务器这种的平台，再通过POST方法和被调用方通信。

当然，如果是客户端程序调用的话，这种方法只是选择之一。主流开发语言都有基于TCP/IP的的类库，比如Socket，所以从实现技术角度讲，完全可以通过两个程序之间连通，而不用通过HTTP。只不过假如开发平台和语言不一样的话，可能会涉及到一些接口插件的问题，需要作额外的开发。

以上是我对Web Service（SOAP）的一些理解，接下来说下REST。看了不少资料，大多都说得比较抽象，我个人觉得SOAP和REST的主要区别在于实现功能的“主体程序”是存在于哪里的。假设现在有个服务器A（包括了数据库），A上有个程序X，程序X的作用为“根据输入参数取得数据并处理数据”，那么在SOAP的实现里，我在客户端通过HTTP的POST方法把需要的参数传过去，然后服务器A上运行程序X，在这个过程里，“主体程序”是存在于服务器A上的。在REST的方法里，通过OData技术，把内部的数据库暴露成“网络版”数据库，通过HTTP的GET方法取得数据，数据取回本地后进行处理，然后把处理结果通过HTTP的POST或者PUT方法修改服务器A数据库上的数据，可见程序处理这块是写在调用端的。

REST的好处是正确地利用了HTTP，因为HTTP是一个应用协议而不是数据传输协议，所以SOAP里利用HTTP的POST方法来传数据是一种偏离了本来设计目的的做法（这也是为什么SOAP也可以在其他协议比如SMTP上实现）。同时也可以看到REST是跟OData紧密联系的，如果不把数据库暴露出来使之可以通过HTTP的方法操作，REST也就没有存在的意义了。

REST的问题，首先我觉得在GET作为URL版的SELECT，功能上是肯定不如真正的SQL强大的，起码一些复杂的查询我不觉得能够用URL实现，而且GET似乎有长度限制，这个可能也是个问题。然后在很多场合下，我们是需要直接调用已经写好了的方法，而不是从数据库取数再自己重新写一遍方法，这种情况下就是只能用Web Service（SOAP）了。

我个人觉得打个比方的话，SOAP/Web Service是把网络资源看成是程序，而REST/OData是把网络资源看是数据库，作用不同，根据场合选择合适的设计模式。

另外想请教下，我是不是把REST理解得比较狭隘，把资源仅仅看成是数据。之前也有看到说把一个服务看成是资源的，这个比较难以理解，我觉得如果是那样的话，那REST会不会变成换了个名字的SOAP？由于本人不做B/S开发，对Web技术的了解也只停留在功能结构层面上，如果有想得不对的地方请不吝指出。

[90天一次满血复活-战忽局]

写到博客里吧

[鸣鸣Amadues]

引用 1 楼 hwasd 的回复:

写到博客里吧

好

[娃都会打酱油了]

服务服务……rest和soap不是提供数据，是提供服务……别搞错了

[鸣鸣Amadues]

引用 3 楼 starfd 的回复:

服务服务……rest和soap不是提供数据，是提供服务……别搞错了

服务只是个概念上的东西。 比如SOAP是提供直接调用程序的服务，本质是客户端通过POST方法把函数的参数和类型传到服务器上。

[鸣鸣Amadues]

引用 4 楼 micropentium6 的回复:

个人觉得啊，你介个概念似乎还有些模糊。 首先说Web service，这也揍是近十几年，随着WWW的出现，才有的东东。你对它的描述有前后倒置的嫌疑。对WS来说，它是RPC的一种。建议你先介绍RPC，然后引出WS，会更自然！ 再说WS里面，SOAP是没法和REST直接比较的。前者是一个协议，后者是一个WS的实现方式。如果要比SOAP可以和ODATA比较一下。 期待大作！

SOAP和REST之所以拿来比较是因为都是用来调用Web上的服务和资源的，但技术实现思路不同。

[小笨和漂向北方]

引用 6 楼 Raffin 的回复:

[quote=引用 4 楼 micropentium6 的回复:] 个人觉得啊，你介个概念似乎还有些模糊。 首先说Web service，这也揍是近十几年，随着WWW的出现，才有的东东。你对它的描述有前后倒置的嫌疑。对WS来说，它是RPC的一种。建议你先介绍RPC，然后引出WS，会更自然！ 再说WS里面，SOAP是没法和REST直接比较的。前者是一个协议，后者是一个WS的实现方式。如果要比SOAP可以和ODATA比较一下。 期待大作！

SOAP和REST之所以拿来比较是因为都是用来调用Web上的服务和资源的，但技术实现思路不同。[/quote] soap的全称是什么？rest是什么？ soap和rest的起源完全不同！soap不一定依赖应用层的协议。比如，通过scoket，借助tcp/ip，一样可以使用soap。在soap/xml出现之前，rpc都是通过二进制数据流完成的。 所以说你非要在http这个层次上，soap必然显得不够灵活。可是，当你了解它出现的历史，你的想法会改变的。

[鸣鸣Amadues]

引用 7 楼 micropentium6 的回复:

[quote=引用 6 楼 Raffin 的回复:] [quote=引用 4 楼 micropentium6 的回复:] 个人觉得啊，你介个概念似乎还有些模糊。 首先说Web service，这也揍是近十几年，随着WWW的出现，才有的东东。你对它的描述有前后倒置的嫌疑。对WS来说，它是RPC的一种。建议你先介绍RPC，然后引出WS，会更自然！ 再说WS里面，SOAP是没法和REST直接比较的。前者是一个协议，后者是一个WS的实现方式。如果要比SOAP可以和ODATA比较一下。 期待大作！

SOAP和REST之所以拿来比较是因为都是用来调用Web上的服务和资源的，但技术实现思路不同。[/quote] soap的全称是什么？rest是什么？ soap和rest的起源完全不同！soap不一定依赖应用层的协议。比如，通过scoket，借助tcp/ip，一样可以使用soap。在soap/xml出现之前，rpc都是通过二进制数据流完成的。 所以说你非要在http这个层次上，soap必然显得不够灵活。可是，当你了解它出现的历史，你的想法会改变的。[/quote] “因为HTTP是一个应用协议而不是数据传输协议，所以SOAP里利用HTTP的POST方法来传数据是一种偏离了HTTP本来设计目的的做法（这也是为什么SOAP也可以在其他协议比如SMTP上实现）。 这个我提到了，只要是基于TCP之类的传输协议，像FTP和SMTP等应用协议，理论上都可以用来作为SOAP的载体，不过HTTP被应用得最广泛才用它的。 Socket是用来连通程序和程序的，既然你用了Socket，就不需要通过SOAP和XML来传输数据了。

[小笨和漂向北方]

引用 8 楼 Raffin 的回复:

既然你用了Socket，就不需要通过SOAP和XML来传输数据了。

这句话本身就是错误的！最早的ｓｏａｐ就是在ｒｐｃ上实现的。 看出来了，你不是来讨论问题的。我不说了就是。你自己玩儿吧！

[鸣鸣Amadues]

如果我有说的不对的地方，也不用这个态度吧。 我觉得重点还是先弄清楚实现的思路，这种技术的起源需求是在A系统里可以远程调用B系统中的的程序，是基于网络的程序模块化思想，实现方法是把程序的接口参数通过网络来传输。 目前用的最多的实现SOAP的技术就是基于HTTP/XML的那种，当然实现方法不止这一种，RPC我刚刚去了解了下，也是数据传输协议的一种封装，自然也可以实现。而且我也没有说过SOAP必须用HTTP和XML实现所以不够灵活。

[小笨和漂向北方]

个人觉得啊，你介个概念似乎还有些模糊。 首先说Web service，这也揍是近十几年，随着WWW的出现，才有的东东。你对它的描述有前后倒置的嫌疑。对WS来说，它是RPC的一种。建议你先介绍RPC，然后引出WS，会更自然！ 再说WS里面，SOAP是没法和REST直接比较的。前者是一个协议，后者是一个WS的实现方式。如果要比SOAP可以和ODATA比较一下。 期待大作！