SOAP and REST (II)
The current SOAP protocol, SOAP 1.1 has been written to support varied uses. It is both a base from which to build new protocols (including RemoteProcedureCalls) and tunnel them over existing ApplicationProtocol's, and a useful means of extending the semantics of those same ApplicationProtocol's. (IJ)
HTTP 1.1 was designed, for the most part, to conform to the RestArchitecturalStyle. The semantics of its methods, though in need of some tighter definition, are defined well enough to get work done. Despite POST being used by some in a way counter to those in the specification, it remains possible to define a use of SOAP over HTTP that preserves the semantics of POST. Indeed, a major difference between SOAP 1.0 and SOAP 1.1 is this capability. (IK)
In this use, "sending a SOAP message" is interpreted more specifically as "POSTing a SOAP message". The value-add of SOAP here is in the envelope; the SOAP headers are used to extend the HTTP processing model by introducing extended transfer semantics, as would normally be done by HTTP headers (except you also get the useful features of "actor" and "mustUnderstand"). But from a REST point of view, the important feature is that the body of the SOAP message represents an entity that will [obey POST semantics]? when being POSTed to the request URL. (IL)
For a SOAP HTTP binding wishing to conform to REST, this means; (IM)
- SoapFaultsShouldNotUseThe200ResponseCode (IN)
- what else? (IO)
SOAP 1.2 and REST (IP)
SOAP 1.2 has a feature known as the "Web Method Specification Feature". This exposes the HTTP method through the binding which allows, among other things, for SOAP users to use GET to retrieve SOAP envelopes that encapsulate the state of the resource identified by the URI. This is radically different than with the common use of SOAP 1.1 (though nothing was stopping people from using GET with SOAP 1.1). (IQ)
Does this mean SOAP 1.2 applications will suddenly become more RESTful? No, probably not. Most SOAP users will probably continue to use SOAP 1.2 as they have SOAP 1.1. (IR)
Discussion (IS)
[PaulPrescod adds] (IT)
- SOAP-using apps should either avoid the use of SOAP messages to do information "gets" or should provide an alternate interface that allows real HTTP get. There will always be more tools out there that know how to do HTTP gets (proxies, spiders, browsers) than tools that know how to interpret your SOAP method as a getter. And more to the point, things that are GET-able through HTTP have URLs that can be linked to and thus integrated into distributed information collections (such as Google or Meerkat) (IU)
[MikeDierken asks] (IV)
- Should cacheable responses use GET only or can POST/SOAP indicate its cacheability? (IW)
There are some strong opinions on this, even amoungst Web architecture gurus. I personally have no problem with SOAP response cachability, as long as it's not the default and is required to be specified explicitly (as it is in 2616 with Cache-Control). It's primarily an optimization though, as one could always use a "see other" response code to redirect to the resource whose representation would be tranferred on the POST response. It may also help simplify things to exclude cacheable responses, but I'm not sure about that. --MarkBaker (IX)
[MichaelRogers? adds/asks] (IY)
- The premise behind SOAP-RPC is to deliver a message in the form of an XML document to a remote method so it can be processed. The software that will process this information should have a security layer, relevant to the security requirements of the application, that will prevent a malicious message from doing harm, right? Shouldn’t we let HTTP deliver a SOAP envelope, that contains the message in an XML document to a specific method and then let that method handle security? Insofar as getting information from your service, you could construct the SOAP-RPC GET to require some authentication before the information is handed out, providing you want to secure your data (the request would naturally be transported via HTTPS). Does this sound right or am I missing the point? (IZ)
I think you're missing the point. You are assuming that HTTP is a transport protocol, and that it therefore exists to carry bits, of which a SOAP-RPC message, which includes a method, is a valid payload. HTTP is not a transport protocol, it is an application protocol. It doesn't send bits, it transfers representational state. If the body of a POST or PUT is not a piece of representational state, you're not doing REST. HTTP already defines the methods, it doesn't need new ones inside the POST body --MarkBaker (J0)
[WaldenMathews adds/asks] (J1)
- The phrase "representational state" causes problems for me because I can find only two reasonable interpretations of it, one of them being too restrictive and the other being not restrictive enough to be useful. If by "representational state" you mean a literal subset of the state of the addressed resource, then you're talking about something that makes sense in the document view of the Web, but not in the view in which resources are conceptual. For example, if I transfer to you a marked-up paragraph which is to replace your second paragraph (is that PUT or POST, by the way?), then I've simply transferred some document state. However, for resources to be truly conceptual, then their change must follow more of an implicit invocation architecture, one in which events are delivered and state changes are implicit and solely at the discretion of the (active portion of the) resource. I believe this to be the modern emerging view of what resources in the web are. In this case, what is transferred really cannot be called "representational state". If we cavil and allow ourselves to call events "state", then the camel's nose is now under the tent, because any bits I send can argue their way to the status of "representational state", even when those bits are really an RPC buzzing in a RESTless pre-call frenzy. (J2)
- In short, when we model things as state plus operations, then we can discuss pre-operation state and post-operation state of a resource or object, but the "state" which directs the operation is not object state, and therefore is not state according to the model. We can nounify anything (VerbsCanAlsoBeNouns), including operations. Usually we call those transactions. If I'm keeping transactions as resources, then "transaction state" takes on meaning. But if I'm not, then we have a hole, and REST and 'conceptual resources' are at odds with one another. (J3)
- What simple insight am I missing? (J4)
I think what you're missing is that some "representational state" refers to what is on the wire - the state of some other resource (though maybe not one with a URI, like application/x-www-form-urlencoded form content) - not the state of the resource that its being transferred to. In the case of PUT, the transferred state represents both the "source" and "target", but that's not the case in general, for either POST or other extension methods. --MarkBaker (J5)
Then, by substitution, REST really stands for "what is on the wire transfer" ... architecture. That's not good enough. 8-( When you say it can be "the state of some other resource", you're talking about the familiar subordinate resource pattern, like when I POST the state of a part to the resource that is the assembly to which it belongs. In that case, what is posted is stateful by my definition above, and the application is essentially just accruing state. Kind of like building a document. But there are other operations that take place that are not conveniently or well described by providing a representation of the resource's final state or the state of anything at all. For example, if my resource is a stock and I 'transfer' to it the parameters of a trade, are you calling the trade 'state'? If so, then there's no problem with RPC, because you just look at the bits on the wire, call them 'state' and REST easy. Am I expecting too much? -- WaldenMathews (J6)
Yes, the record of a trade is a representation of the state of that trade. The trade itself may or may not have a URI though. RPC's "bits on the wire" aren't state, they're instructions. It would be analogous to comparing an RPC invocation to the entire HTTP message, rather than to the body. (J7)
Whether or not the trade has a URI, it has an identity separate from the identity of the stock. The same stock (or any other economic resource) might be traded many times. Likewise the type of trade will have implicit or explicit state transition rules, and the instance of a trade will undergo probably explicit state changes according to those rules. In other words, it could be a Web resource with a URI, its state could be represented, and it could even be an example of StateMachineAsHypertext. -- BobHaugen (J8)
Are you folks suggesting that an operation has 'state'? I'm suggesting that an operation is defined as a function from pre-condition to post-condition, i.e., from one state to its successor state. A change is by definition the antithesis of state. Sure, anything we can capture information from can be frozen into a 'record' of change, and that record has trivial state*, but I'm not interested in the record here, just the change. I don't understand Mark's analogy above, but I may get at it with this challenge (to anyone): show me something you call RPC, and I'll show you that it's always 'representational state', if I choose to cast it in that light. -- WaldenMathews (J9)
- Trivial state because mutability would make no sense. (JA)
''Walden, I don't understand your point. But it seems from the several Rest-wiki pages to which you've contributed that you are putting a lot of serious thought into it. So I'll try two lobs into the territory to see if we can connect. (JB)
- "Trade" could mean an operation or "a trade" could mean the record of an operation. 2. State is used in at least two different ways in these discussions: as in state machine, and as in the values of the properties of a resource. (JC)
Are you thinking of a trade as an operation? Aren't there several operations associated with a trade? Isn't each trade recorded for auditing and other purposes? Wouldn't that record be a resource in some address space, if not URI? I'm not familiar enough with financial trading to understand all the state changes of a trade, but you've used purchasing in other examples, so here are some states of a purchase order: offered, accepted, rejected, fulfilled (goods or services delivered), paid. (JD)
A delivery of goods or services or a payment is similar to a trade, in that title to some economic resources is transferred from one party to another. A payment is recorded as a Cash Disbursement by the payer, a Cash Receipt by the receiver, and a Funds Transfer by the payment intermediary. The Funds Transfer has at least two states, disbursed and received, and there may also be error states. (JE)
That's beside the usual interpretation of state in REST which I think means more like the values of the properties of the resource - e.g. for a trade, the stock symbol, the number of stocks in play, the price, the parties to the trade, the time, etc. (JF)
Of course there are associations between named states in a state machine and the values of the properties of the resource undergoing state transitions. (JG)
But (I think) the state in Representational State Transfer means representation of the values of the properties of the resource, whereas state as in state machine is usually recomended to be made into a subresource in REST circles. (JH)
Did that help to communicate? Or just make things more confused?'' -- BobHaugen (JI)