This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

REST vs. SOAP

Stefan Tilkov,

A long and thoughtful post from Anne Thomas Manes on REST vs. SOAP. Anne is usually right, but I have to question this statement:

Per the SOAP specification, the SOAP node determines what method to invoke based on the qualified name (QName) of the child element of the SOAP Body element.

While this may be a convention, I cannot find any mention of “invoking a method” in the spec. The SOAP spec does neither mandate nor suggest any relationship between a message and a method, which is a good thing.

I also find it very hard to agree with this assertion:

SOAP is also an application protocol, with its own set of application protocol semantics.

In my view, it may be valid to describe SOAP as a toolkit for constructing application protocols (if you are so inclined). But an application protocol in itself? I don’t think so.

On September 18, 2005 5:03 PM, Bill de hÓra said:

I have to agree.

On method mapping: there’s no default. In terms of the “Semantics” word, even agreeing with that claim that there is a mapping won’t be sufficient; you have to describe how the SOAP message is going to be evaluated. Mapping just begs the question of what will happen.

On SOAP as an app protocol: I always saw SOAP as being closer to BEEP than any of the current Internet app protcools. And calling SOAP an app protocol is like calling XML a vocabulary.

On September 19, 2005 2:02 AM, Mark Baker said:

SOAP is split-brained, both by specification and common practice. It is usable - as you point out - as a toolkit for constructing application protocols. But it’s also usable as an application protocol extension protocol (yes, that’s the word “protocol” twice - look up “PEP” at w3.org); that is, a protocol which extends (rather than layers-on-top-of) the underlying application protocol. Henrik and I made sure that SOAP 1.2 was usable in this fashion, though it appears that the ImmediateDestination issue (recently brought to light in the context of WS-Addressing) was an oversight.

On September 19, 2005 11:43 PM, Anne Thomas Manes said:

My mistake, Stefan. The SOAP spec does not specify the processing model for mapping a request to a method.

The WS-I Basic Profile does:

4.7.6 Operation Signatures

Definition: operation signature

The profile defines the “operation signature” to be the fully qualified name of the child element of SOAP body of the SOAP input message described by an operation in a WSDL binding.

In the case of rpc-literal binding, the operation name is used as a wrapper for the part accessors. In the document-literal case, since a wrapper with the operation name is not present, the message signatures must be correctly designed so that they meet this requirement.

An endpoint that supports multiple operations must unambiguously identify the operation being invoked based on the input message that it receives. This is only possible if all the operations specified in the wsdl:binding associated with an endpoint have a unique operation signature.

R2710 The operations in a wsdl:binding in a DESCRIPTION MUST result in operation signatures that are different from one another.

On September 21, 2005 3:55 AM, Parand Tony Darugar said:

Stefan,

While this may be a convention, I cannot find any mention of “invoking a method” in the spec. The SOAP spec does neither mandate nor suggest any relationship between a message and a method, which is a good thing.

Help me out with this one. I’ve seen a lot of practical problems because of the lack of an explicit relationship between the message and a method, primarily around toolkit interoperability (a message from one toolkit could not be digested by another toolkit).

The situation could be more accurately described as the receiver of the message not knowing what method or handler to invoke for that message. I don’t think there is an alternate place to specify this within SOAP, short of using something like ws-addressing.

So are you saying it’s not necessary or even bad to specify the method within the message, that it should go somewhere else, that it’s the job of the underlying protocol to get the message to the appropriate method listener, or something else all together?

On September 21, 2005 8:37 AM, Stefan Tilkov said:

Assuming SOAP is used in a non-restful way, I agree the message is the only place information about the “intent” can be stored. This may be in a wsa:Action header, or it may be the QName of the message body’s root element. My point is, though, that any connection to a method or operation is something that is outside the scope of the SOAP spec, and in fact the SOAP processing model: whether it’s a single handler whose handleMessage gets invoked for all messages, or one per message type, or one per wsa:Action header, or some combination, is a decision completely localized within the toolkit used on one side of the communication.

I am aware that most toolkits, including .NET and JAX-RPC/JAX-WS, do things differently and indeed create a tight association between a message type and a method. That doesn’t necessarily mean they’re right, though :-) If you are following this path, I suggest you follow Annes advice (see the link above) — this is probably your best bet for the moment with regards to interop.

On September 21, 2005 9:10 PM, Parand Tony Darugar said:

My point is, though, that any connection to a method or operation is something that is outside the scope of the SOAP spec, and in fact the SOAP processing model:

That’s the part I’m trying to understand better. Let’s forget for the moment which method or operation the message is handled by. The question can also be asked as, how does the receiving party identify what type of message it’s receiving?

As mentioned, in REST the handler or the type of message is identified by the URL it’s sent to. In SOAP that’s not the case. Let’s take the position that we want the receiving party to handle this as it chooses. How can it make the determination? It has to have a way of identifying the type of the message. Even if all requests are handled by the same receiver, that receiver has to be able to discern what type of message it just got in order to handle it in the appropriate way.

Which is my way of asking, what’s the identifier that determines the type of the message? What’s SOAP’s equivalent to REST’s URL? Perhaps it’s the full signature of the XML document being sent? But that doesn’t work well, because you can have two identical documents express different intent based on state or context. WS-I and convention tell us the identifier is the QName of the child element of the SOAP Body element, but I’m not a big fan of that, so I’m wondering if there’s a better way.

On September 21, 2005 10:36 PM, Stefan Tilkov said:

I think you have answered your own question already — either you depend on the message body element’s QName, or you have to find something alternative. In case of SOAP/WS-*, the analogy to the REST URL would be the wsa:Action header.

In my view, though, that’s not really superior — I like having distinct types of messages (as identified by the the root element name) better (if you don’t want to go down the REST route in the first place).

If there’s another way, I’m not aware of it.