SOAP vs. REST: Pragmatic case studies?

I'm not satisfied with the answers given by the SOAP vs REST questions notably here: Performance of SOAP vs. XML-RPC or REST

because it's just general philosophical answers and not pragmatic answers with some study cases.

Nobody can give precise case开发者_开发知识库s of when soap would be more suitable than rest, especially as for performance point of view ?

Update:I think REST is winning the war.

Performance is not the deciding factor.

First I should say, asking a SOAP-vs-REST question is a little cockeyed, because SOAP is a XML envelope format, and REST is an architecture. So I will make a little assumption and suppose that you are really considering SOAP-vs-POX or SOAP-vs-JSON or SOAP-vs-some other data formatting approach.

The deciding factor should be this:
Do you now need, or will you need in the future, the SOAP envelope?

The SOAP Envelope allows things like framework-provided encryption, digsig, routing, and authorization checks, among other things. You can of course, do those things with REST (or more accurately, with plain-old-XML, or JSON, etc) but you have to do more work yourself, to make that happen.

If Performance - whatever you construe it to mean - really is your #1 criterion, then you should probably abandon SOAP and POX and move to protobufs or something else optimized for performance. These can be faster to serialize and faster to transmit.

If you think this answer is "too philosophical" and you really want hard figures, well, then I suppose you'll need to conduct some tests. The actual perf will vary greatly on the toolkits you choose, the shape of the messages, and the extra data services (like encryption and so on) that you use. But in the end, perf won't be, or shouldn't be, decisive either way.

If your SOAP toolkit is 20% easier to use. debug, and maintain as your POX toolkit, then you should use SOAP, regardless of the performance. People (coders, architects, testers) are much more expensive than CPUs and networks these days. You can always buy another 2 cpus, or a bigger network, if necessary, and if your design is correct. But you can't buy 20% less time developing, at any cost, if your framework is hard to use, or if it drives away your people. Unless you are running a geo-scale network, you will do better to optimize for the people, instead of for the network.

You can find an article comparing REST and SOAP here: http://www.jopera.org/files/www2008-restws-pautasso-zimmermann-leymann.pdf

Authors conclusions seemed to be:

• Use RESTful services for tactical, ad hoc integration over the Web
• Prefer WS-* Web services in professional enterprise application integration scenarios with a longer lifespan and advanced QoS requirements

Personally I do not like terminology like "professional enterprise" because it is loose and informal. However in my opinion authors made some good points in the article. Maybe to conclude and to give some own thoughts:

• If you want to make API public - do it in RESTful way. Why? It is simple to use for a client application so it will make your service more popular. For example Amazon is exposing both REST and SOAP APIs, but 85% of their users have chosen REST version Amazon API - SOAP vs. REST

• Use SOAP and WS-* stack if you will create (or you have some control of the process of creating) both consumers and producers of your services and you do need advanced features of WS-*. This will probably required more resources also because SOAP applications tends to be "heavier" (more features, but more sophistication also).

Also considering performance REST could be faster (messages are definitely shorter and you do not need to parse xml).

Hope it will help.

In your example of flash client - it is really hard to tell without knowing the details, however if one do not need all this security and transactional features of WS-* I think building REST application would be simpler and faster.

Answering to comment

I should use soap because i'm in so called "professional enterprise"

And assuming of course that your choice isn't really dictated by big software vendors.

SOAP is suited for bigger enterprises because it encourages more formal approach. It offers specifications, which are huge, so your developers may need time to learn them and maybe even some professional training --> so spending companies resources. It also offers tools - and not all of them are open source, so this can also mean additional resources. But if your team will learn this way of integrating services it will probably be efficient and resulting code will be high quality.

REST in contrary is more a philosophy of developing applications. So, no huge specifications, no specialized tools. No resource spending. This may work nice if you have a small team of good programmers - they will not need so many guidelines if they know the basic principles . Unfortunately it is also easier to do things wrong.

Another thing to consider is the applications size - the richer the API, the more services you want to integrate, the harder it will be to do it RESTful. Also building small SOAP application wouldn't be probably a good idea - whole overhead and entrance cost is just too high.

You need to evaluate pros and cons for your project. It is impossible to give recommendation without knowing all the details I think.

And finally - this has nothing to do with reasonable arguments but more with politics. I think that management level people seem to prefer WS-* stack and SOAP (it has support of "big enterprises" so it is easier for them to justify their choose). On the other hand people from academic background[1] prefers REST - because there is still a lot of research that can be conducted in the area.

[1] I'm somewhere in between, so I can observe both behaviors ;-)