java Soap 网络服务请求与 HTTP POST 请求？

Soap webservice request vs HTTP POST request?

提问by emilly

I am coming from servlet/web application world and started learning web services(SOAP based). I have gone through some of the webservice tutorials. I am trying to draw the parallel between normal http request and webservice request. Here are my observations ;-

我来自 servlet/web 应用程序世界并开始学习 web 服务（基于 SOAP）。我已经阅读了一些网络服务教程。我试图在普通 http 请求和 web 服务请求之间进行比较。这是我的观察；-

1)Both are HTTP request. Webservice is a also post request which contains soap envelope as request body. Soap envelope is just a normal xml which contains the data

1）两者都是HTTP请求。Webservice 也是一个 post 请求，其中包含肥皂信封作为请求主体。Soap 信封只是一个包含数据的普通 xml

2)java Stub internally marshal the XML , creates HTTP request and send it to consumer

2)java Stub 在内部对 XML 进行编组，创建 HTTP 请求并将其发送给消费者

3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service.

3）消费者端的Servlet拦截请求并将其分解为java对象并将其发送给相应的服务。

Is my observation correct ? I know there may be other complexities but i tried to put the comparison in simple manner.

我的观察是否正确？我知道可能还有其他复杂性，但我试图以简单的方式进行比较。

回答by GPI

Your assumptions are generally correct. Yet, the subtelties can lead to huge differences.

你的假设通常是正确的。然而，细微之处可能会导致巨大的差异。

Claim 1 : both are HTTP.

声明 1：两者都是 HTTP。

SOAP is generally used with an HTTP "binding". Yet it does not have to be that way. SOAP is designed to be fairly transport agnostic. It is not uncommon to have SOAP being used over JMS (although one might consider this an overuse of JMS, and an over architected protocol), it is certainly in production in many places. Rarely seen are SOAP/SMTP or SOAP/TCP without HTTP, but these exist too.

SOAP 通常与 HTTP“绑定”一起使用。然而，它不必是那样。SOAP 被设计为与传输完全无关。在 JMS 上使用 SOAP 并不少见（尽管人们可能认为这是对 JMS 的过度使用，以及过度架构的协议），但肯定在许多地方都在生产中使用。很少看到没有 HTTP 的 SOAP/SMTP 或 SOAP/TCP，但它们也存在。

Webservice is a also post request which contains soap envelope as request body

Webservice 也是一个 post 请求，其中包含肥皂信封作为请求主体

A SOAP call over HTTP is a POST request. It may not be of content-type xml, though, as some variants such as SwA (SOAP with attachments) or XOP+MTOM variants may produce HTTP payloads that are MIME/Multipart (the first part of which is the SOAP Enveloppe in its pure XML form).
This use cas is most common when on is to send large binary content over a SOAP Call, and for which binary encoding may add a large weight to the request (base64 is a 1.3x factor in weight).

HTTP 上的 SOAP 调用是一个 POST 请求。但是，它可能不是内容类型的 xml，因为某些变体，例如 SwA（带附件的 SOAP）或 XOP+MTOM 变体可能会产生 MIME/Multipart 的 HTTP 有效负载（其中的第一部分是纯 SOAP Enveloppe XML 格式）。
当通过 SOAP 调用发送大型二进制内容时，这种使用 cas 最常见，并且二进制编码可能会给请求增加很大的权重（base64 是权重的 1.3 倍）。

java Stub internally marshal the XML, creates HTTP request and send it to consumer

java Stub 在内部编组 XML，创建 HTTP 请求并将其发送给消费者

That is the usual way it is done, Axis framework and JAXWS frameworks work primarily this way.

这是通常的完成方式，Axis 框架和 JAXWS 框架主要以这种方式工作。

The older SAAJ API, a standard EE API, requires you to build your SOAP Message by hand, using the DOM APIs, (see SOAPMessageFactory), and then send it.

较旧的 SAAJ API（一种标准的 EE API）要求您使用 DOM API（请参阅 参考资料SOAPMessageFactory）手动构建 SOAP 消息，然后发送它。

If you look at Spring WS, you'll have something close to your claim, but where each part is fairly exposed and in your control (you may elect to build certain calls with a DOM Api, others by using JAXB marshalling, ...).

如果您查看 Spring WS，您会发现一些与您的主张相近的东西，但是每个部分都相当公开并在您的控制之下（您可以选择使用 DOM Api 构建某些调用，其他调用使用 JAXB 编组，... ）。

3)Servlet at consumer side intercpets that request and unrmashal it to java object and send it to corresponding service

3）消费者端的Servlet拦截请求并将其解混为java对象并将其发送给相应的服务

Again, this is how things generaly work. But you can also have an implementation that works outside a servlet container. (See Endpoint Service API in JAX WS).

同样，这就是一般情况下的工作方式。但是您也可以有一个在 servlet 容器之外工作的实现。（请参阅 JAX WS 中的端点服务 API）。

回答by siddhartha chakraborty

Your assumptions are right:-

你的假设是正确的：-

Yes, Servlet request and Web service request both are normal HTTP request and yes, SOAP web service internally use HTTP POST.

是的，Servlet 请求和 Web 服务请求都是普通的 HTTP 请求，是的，SOAP Web 服务内部使用 HTTP POST。

Yes,java internally marshal the XML. Also, at client end one java web service client(may be a wrapped in servlet) un-marshal it. A SOAP messageor SOAP type web service has many characteristics like:-

是的，java 在内部对 XML 进行封送处理。此外，在客户端，一个 Java Web 服务客户端（可能是包装在 servlet 中）对其进行解组。一个SOAP消息或SOAP类型的Web服务有许多特性，如： -

• SOAP message mostly send data using XML format. XMLs are technology independent. So, SOAP can interact with two heterogeneous web applications built in two separate technologies and exchange data using XML.
• SOAP web services send XML using HTTP protocol. Data are sent wrapped in an XML using the payload of HTTP.
• SOAP web services can be secured. For an example, all the payment related transactions using credit card and bank info are done using secured SOAP web services.
• A SOAP web service accepts XML in request and returns XML in response. In case of errors this return XMLs can also contain SOAP faults. SOAP faults contain the description of error and an error code.
• Web services can carry attachment document also like PDF, Word etc. with its XML payload. Java provides separate API for this type of web services. There is an API available in java called SAAJ to accomplish this.

• SOAP 消息大多使用 XML 格式发送数据。XML 与技术无关。因此，SOAP 可以与使用两种不同技术构建的两个异构 Web 应用程序交互，并使用 XML 交换数据。
• SOAP Web 服务使用 HTTP 协议发送 XML。使用 HTTP 的有效负载以 XML 格式发送数据。
• 可以保护 SOAP Web 服务。例如，所有使用信用卡和银行信息的支付相关交易都是使用安全的 SOAP Web 服务完成的。
• SOAP Web 服务在请求中接受 XML 并在响应中返回 XML。如果出现错误，此返回的 XML 还可以包含 SOAP 错误。SOAP 错误包含错误描述和错误代码。
• Web 服务也可以通过其 XML 负载携带附件文档，如 PDF、Word 等。Java 为此类 Web 服务提供了单独的 API。java中有一个名为SAAJ的API来实现这一点。

回答by abarisone

I think that you can find a very good response in this blog postby Ben Klopfer.

我认为您可以在Ben Klopfer 的这篇博文中找到很好的回应。

Mainly the difference between XML/SOAP vs HTTP/REST is that the former is most response verbose while the latter is lighter.

XML/SOAP 与 HTTP/REST 之间的主要区别在于，前者响应最冗长，而后者更轻。

But this is not the only aspect you have to take into account. REST represents the state of the resource and is a little bit easier to use and to understand, and always remember that it comes afterwards compared to SOAP. In addition SOAP it is not limited to using HTTP/HTTPS, but can be also used with other transports like SMTP, JMS, etc.

但这并不是您必须考虑的唯一方面。REST 代表资源的状态，更容易使用和理解，并且永远记住，与 SOAP 相比，它是在后的。此外，SOAP 不仅限于使用 HTTP/HTTPS，还可以与其他传输方式一起使用，例如 SMTP、JMS 等。

Resuming the post reminds you:

恢复帖子提醒您：

Use SOAP when:

• All you need is simple operations, like read only methods

• Implementing a one-way or one-object service for something like data exchange or transfer

• You want finer control over the specific transport of data, or can't always use HTTP

• Rigid specifications need to be enforced on incoming requests, and you want to minimize additional documentation needed for use

• You can rely on client ability to parse XML, or more preferably SOAP itself

• You need built-in error handling when things go wrong with requests

Use REST when:

• Operations are complex, like create/read/update/delete on objects

• Implementing a multi-faceted service for a variety of different objects

• You want to easily and quickly target a variety of consumer end user devices as clients

• Requests are generally stateless, like call and response compared to a conversation

• Your clients may have limited bandwidth or processing power

• You can leave it up to the client to get their requests correct and to deal with problems

在以下情况下使用 SOAP：

• 您只需要简单的操作，例如只读方法

• 为数据交换或传输等实现单向或单对象服务

• 您想要更好地控制特定的数据传输，或者不能总是使用 HTTP

• 需要对传入的请求强制执行严格的规范，并且您希望尽量减少使用所需的额外文档

• 您可以依赖客户端解析 XML 的能力，或者更优选 SOAP 本身

• 当请求出现问题时，您需要内置的错误处理

在以下情况下使用 REST：

• 操作很复杂，比如创建/读取/更新/删除对象

• 为各种不同的对象实现多方面的服务

• 您希望轻松快速地将各种消费者终端用户设备作为客户端

• 请求通常是无状态的，例如与对话相比的呼叫和响应

• 您的客户的带宽或处理能力可能有限

• 您可以将其留给客户来正确处理他们的请求并处理问题