最近，我的任务是在SOAP / REST时代之前采用旧的Web服务，并使其与当前的Web服务“标准”相提并论。这是非常直接的服务，HTTP（s）POST XML，做一些事情，并用XML作为一个非常面向消息的服务。
“web”服务最常用的两个选项是SOAP和REST ......
虽然从技术上讲，SOAP可以完美地适应我的应用程序，但它感觉非常繁重，并且确实不需要任何WS- *功能。我的意思是确定它确实做SSL和简单的用户名/密码验证，但WS - *！@ $ @ $ @ 1 !!!谁需要它？！至少不是我和我对那些做的人表示哀悼（我确信在正确的情况下它是很好的技术;））
现在我喜欢REST，因为它看起来很轻盈。事实上，我能够采用一个非常流行的REST框架，如Jersey，并实现Web服务的每个功能。事实上，我设法将代码库从数千行代码中减少到100行代码。显而易见的是，在旧服务中正在进行大量的手动工作来解析XML并映射到正确的函数调用等...
REST有什么问题？
在高层？什么都没有（你可以坐下来争论利弊，直到奶牛回家）。这篇文章/问题不是SOAP与REST的火焰战争。但为什么大多数人选择沿着这条路走下去呢？
虽然我能够使用Jersey和REST实现100％的服务，但是如果有的话，我几乎设法打破了“REST”的所有规则。
但是效果太棒了！ :)但我打破了规则：P
一个例子，我的应用程序有数百个“错误”代码。 REST人员喜欢说地图到400 Bad Request并将你的理由放在体内。但是我说当我只是简单地返回XML响应中的代码时，为什么还要麻烦。为什么会混淆客户端（Developer），只需解析一个代码？
因此，如果SOAP很重并且REST似乎更倾向于CRUD和面向资源的应用程序类型，那么轻量级“Web”服务的选项有哪些？ XMLRPC？为什么人们正在盯住REST或者我错过了什么？
让乐趣开始吧！ ：）
答案 0 :(得分：2)
如果您很高兴重新发明一个经过测试的分布式应用协议（如HTTP），那么请随意。