0

I'm about to implement a web service in REST.
I have a huge problem in the inter continental connection that sometimes goes slow and unstable with packet losses.

I'm in control of both sides, client and server. The client that performs calls to the server many times per second. Sometimes it sends more data into only one connection to deal with this internet problem.
I have read a lot about the differences of REST and SOAP and i know that SOAP envelope is bigger than REST data.

My question is, since both are over http, is there any diference, besides the data size, between both? What you would use?

Ivan Pereira
  • 2,149
  • 3
  • 24
  • 32

3 Answers3

2

As you've hinted, it's not really a matter of SOAP vs. REST, but a matter of message size and message frequency.

If the protocol (number and frequency and pattern of messages) is the same for REST and SOAP, then the only real difference is the message size. However, a truly RESTful system design may not have the same communication pattern as a SOAP version because REST involves manipulation of Resources rather than messages to methods at an endpoint. REST uses a uniform set of standard verbs (PUT, POST, GET, DELETE), quite unlike SOAP. Hard to say more without knowing more about your design.

The "correct" solution depends on whether you value latency (focus on the individual messages) or throughput. If you want a higher probability of each call succeeding (i.e. you value latency), then smaller is better if it results in fewer packets - but this may not be the case if the SOAP message is also relatively small. For throughput, batching messages together may be better, regardless of SOAP vs. REST.

The answers to this question may also be useful.

Finally, note that REST is an architecture, whereas SOAP is a protocol - REST doesn't specify that you even have to use HTTP, and it doesn't specify the payload format either. So whilst a REST implementation will typically have smaller messages, it isn't guaranteed.

Community
  • 1
  • 1
DNA
  • 42,007
  • 12
  • 107
  • 146
0

One difference between the two is that there is a WS-ReliableMessaging standard (implemented by WCF) which creates a protocol which ensures that your messages arrive, and that they arrive in the correct order. If reliable message delivery, even on a lossy network, is a requirement, then this is a huge advantage of SOAP over REST.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
0

A SOAP interface can be made RESTful, so I'm assuming that you're thinking about SOAP vs minimalistic protocol (XML or JSON, no enveloppe).

The main technical factor as you pointed out is the size of the messages. 'Custom' REST give you more flexibility to design the payload and headers exactly as you want them, and a SOAP enveloppe can add a non trivial size to small frequent messages.

Subjectively, SOAP libraries often entice you to rely on states, sessions, non idempotent operations, or other non-RESTful patterns which would be a liability in your case. You can always refuse the temptation, but it's like trying to do session-less JSF - it comes back at every corner of the code.

Overall, I'd go with REST.

That said, if your messages are large and must be delivered SOAP might have advantages. Personally I like the 'disposable clients, servers AND network' shotgun approach with small stateless idempotent and non transactional messages better when I can get away with it - but it makes protocol design more critical.

ptyx
  • 4,074
  • 1
  • 19
  • 21