网络编程：SOAP 与使用 XML 库的 DIY 编组？
我知道已经有很多关于 SO 的讨论，涉及 SOAP、膨胀、XML 和 REST 等替代机制。
情况是这样的。一位新的团队成员确实基于手动实现协议的困难而谈论 SOAP。他推荐 gSOAP（项目全部用 C++ 编写）。他说 WSDL 清理了大量混乱的手工编码 C++。
现在，我正在使用基于 XML 的文本消息和 expat XML 库来处理大多数网络。因此，我有一些与修改消息格式或添加参数列表相关的编程工作（不多）。在发送端，我打包一个 XML 请求并通过普通的旧 TCP 套接字发送它。在接收方，我使用 DOM 或 SAX 解析 XML。等等，到目前为止效果很好。 XML 消息非常紧凑，平均最多只有几百个字符。我理解这些消息中的每一项。
我们希望使用 PHP 编码的网站可以访问产品的一部分（服务器）。这在一定程度上推动了这个想法，即 SOAP 接口对于脚本编写者来说将“更容易”。该项目中的每个人都相信 SOAP 是他们的救赎。
我认为引入像 gSOAP 这样的新大型库对成熟项目的势头具有极大的破坏性。
我想知道是否有一种不同的、更紧凑的方式来完成 SOAP 为我们提供的功能。以及如何平衡 gSOAP 或其他 SOAP 工具的主张，使开发生活更轻松与残酷的现实。
IE，有人告诉我 WSDL 比使用 XML 库手动编写 C++ 更好、更容易、更熟练等。它将 C++ 对象的语义直接放入网络消息的声明中。问题是，我定义的许多 XML 消息并未在接收端一对一地映射到单个不同的对象。
或者，也有可能我什么都不担心。
但当我浏览这里的消息时，现实似乎与我在当地被告知的内容相矛盾。
I know that there are a lot of discussions already on SO about SOAP, bloat, XML, and alternative mechanisms like REST.
Here's the situation. A new team member is really talking up SOAP based upon the difficulty of implementing protocols by hand. He recommends gSOAP (project is all in C++.) He is stating things like WSDL cleaning up lots of messy hand coded C++.
Right now I am handling most networking with XML based text messages, and the expat XML library. So I have some programming effort (not much) associated with modifications to message formats or additions to parameter lists. At the sender end I package up an XML request and send it over a plain old TCP socket. At the receiver I parse the XML using DOM or SAX. Etc. It has worked fine so far. The XML messages are quite compact and average a couple of hundred characters, at most. And I understand every item in those messages.
We want one portion of the product (a server) to be accessible to web sites that are coded using PHP. That is partly driving this idea here, that a SOAP interface will be "easier" for script writers. Everyone on this project believes that SOAP is their salvation.
I see the introduction of a new large library like gSOAP as highly disruptive to the momentum of a mature project.
What I am wondering is if there is a different and more compact way of doing what SOAP gives us. And how to balance claims of gSOAP or other SOAP tools making development life easier against hard reality.
IE, I am being told that WSDL is better, easier, more workmanlike, etc than hand coding C++ using an XML library. That it puts the semantics of the C++ objects right into the declaration of the network messages. The thing is, many of the XML messages that I have defined don't map one for one to a single distinct object at the receiving end.
Or, it is possible that I am worrying about nothing.
But the reality as I scan messages here seems to contradict what I have been told locally.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不会买肥皂。
Don Box 最初设想的简单对象访问协议现在一点也不简单。它已经变成了一个臃肿的、由委员会设计的混乱局面。
再加上对臃肿的库的所有额外依赖，你的手上可能会出现一团糟。
工具供应商喜欢 SOAP，但我不认为其他人喜欢 SOAP。
I'm not buying SOAP.
Don Box's original vision of a Simple Object Access Protocol is anything but simple now. It's become a bloated, design by committee mess.
Throw in all the additional dependencies on bloated libraries and you have a potential mess on your hands.
Tool vendors love SOAP, but I don't see much for anyone else.
我想您会发现 PHP 开发人员更有可能更喜欢 RESTful 接口。这是 2003 年的一篇关于它的文章。
http://onlamp.com/pub/a/php/ 2003/10/30/amazon_rest.html
RESTful 接口是一种日益增长的现象，如果您需要吸引开发人员使用您的平台，那么如果您赶上潮流就会更容易。
话虽如此，是否有充分的理由不能支持多个接口？这在没有固定受众的 Web 服务中相当常见。您可以支持旧模型、干净的 RESTful 模型和 SOAP/WSDL 模型。然后在 6 个月到一年后进行盘点，看看哪种模型最受欢迎且支持起来最少。
当谈到使网站更容易被外部人员访问时，REST 的使用更为广泛。至于保存您的项目，SOAP 可能会这样做，因为它要求接口设计具有一定的严谨性，但 REST 也是如此。如果这是一个关键标准，那么您可能应该放弃手动编码的 XML，而采用可以作为 REST 和 SOAP 实现的高级接口设计。
我知道有些人认为 SOAP 和 REST 是根本不同的方法，但如果您采用 RESTful 方法进行界面设计，那么创建 SOAP 版本应该不会有太大困难。但不要试图反其道而行之。
I think that you will find that PHP developers are more likely to prefer RESTful interfaces. Here is a 2003 article about it.
http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html
RESTful interfaces are a growing phenomenon and if you need to attract developers to your platform it will be easier if you catch the wave.
Having said that, is there a good reason why you cannot support multiple interfaces? This is fairly common in web services that do not have a captive audience. You could support your legacy model, a clean RESTful model and a SOAP/WSDL model. Then take stock after 6 months to a year to see which model is the most popular and least effort to support.
When it comes to making the site more accessible to outsiders, REST has more widespread usage. As far as saving your project, it is possible that SOAP would do this because it demands a certain amount of rigor in interface design, however the same could be said of REST. If this is a key criterion, then you should probably abandon the hand-coded XML and go with a high-level interface design that could be implemented as both REST and SOAP.
I know some people believe that SOAP and REST are fundamentally different approaches, but if you take a RESTful approach to the interface design, you shouldn't have great difficulty in creating a SOAP version. Don't try to do it the other way around though.
这是经典的、搞笑的、对 SOAP 的揭穿 - “S”代表“Simple”。我所在的社区已完全转换为 REST。
Here is a classic, hilarious, debunking of SOAP - The "S" stands for Simple". The community I move in is completely converted to REST.
如果您浏览一下网络上的 RESTful 接口，您会发现 SOAP 几乎被普遍避免。 SOAP 是如此复杂，以至于它有效地锁定了没有现有 SOAP 包的语言，因为没有人会自己实现它。另一方面，原始 XML 在这一点上相当通用，并且如果需要的话在内部实现并不困难。
If you look around at RESTful interfaces on the net, you'll notice that SOAP is nearly universally avoided. SOAP is such a complex beast that it effectively locks out languages with no existing SOAP package, since nobody is going to implement it themselves. Raw XML, on the other hand, is pretty universal at this point, and not that difficult to implement in-house if necessary.