6

Duplicate: This is a duplicate of "What are the best uses of REST services?" and many others. Please close it.

In web development:

Should i learn RESTful services very well and make all my future projects using it? Is it faster than SOAP services? When to use which?

Are there certain cases I should prefer one of them?

Community
  • 1
  • 1
Amr Elgarhy
  • 66,568
  • 69
  • 184
  • 301
  • This is a duplicate of http://stackoverflow.com/questions/973796/what-are-the-best-uses-of-rest-services and many others. I'd have voted to close, but have reached my daily limit. – John Saunders Jun 14 '09 at 17:02
  • possible duplicate of [SOAP or REST for Web Services?](http://stackoverflow.com/questions/76595/soap-or-rest-for-web-services) – Michael Irigoyen May 24 '13 at 15:51

8 Answers8

6

In my experience, SOAP adds some overhead that you can avoid by making a RESTful service. That being said, in your decision, you should consider your audience. If you are expecting to have a large variety of outside-world consumers of your service, I would recommend SOAP, because there are a lot of tools that automatically generate a programmatic interface to it.

Some web services, like PayPal, offer multiple alternatives, so you could also consider choosing both.

Jacob
  • 77,566
  • 24
  • 149
  • 228
4

REST should be faster than SOAP in most cases since it is more light weight, less overhead.

But there are some situations in which you need the functionality that is in that overhead.

Unless you want to standardise on one (this reduces the number of technologies in your solution, and therefore the complexity), the rule of thumb would be use REST when you can and SOAP where you must.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
3

Simple Object Access Protocol (SOAP) standard an XML language defining a message architecture and message formats, is used by Web services it contain a description of the operations. WSDL is an XML-based language for describing Web services and how to access them. will run on SMTP,HTTP,FTP etc. Requires middleware support, well defined mechanisam to define services like WSDL+XSD, WS-Policy SOAP will return XML based data SOAP provide standards for security and reliability

Representational State Transfer (RESTful) web services. they are second generation Web Services. RESTful web services, communicate via HTTP than SOAP-based services and do not require XML messages or WSDL service-API definitions. for REST no middleware is required only HTTP support is needed.WADL Standard, REST can return XML, plain text, JSON, HTML etc

t is easier for many types of clients to consume RESTful web services while enabling the server side to evolve and scale. Clients can choose to consume some or all aspects of the service and mash it up with other web-based services.

REST uses standard HTTP so it is simplerto creating clients, developing APIs 2.REST permits many different data formats like XML, plain text, JSON, HTML where as SOAP only permits XML.
REST has better performance and scalability.
Rest and can be cached and SOAP can't 5.Built-in error handling where SOAP has No error handling
REST is particularly useful PDA and other mobile devices.

REST is services are easy to integrate with existing websites.

SOAP has set of protocols, which provide standards for security and reliability, among other things, and interoperate with other WS conforming clients and servers. SOAP Web services (such as JAX-WS) are useful in handling asynchronous processing and invocation.

For Complex API's SOAP will be more usefull.

kapil das
  • 2,061
  • 1
  • 28
  • 29
2

One factor is that RPC communications are often not cached as part of the HTTP stack because the caching middleware shouldn't need to understand the contents of the request. So, RESTful systems can take better advantage of caching.

aehlke
  • 15,225
  • 5
  • 36
  • 45
  • 1
    +1: Leveraging the standard HTTP caching infrastructure is a huge performance win for REST services, probably orders of magnitude more important than smaller payload size. – Jim Ferrans Aug 20 '09 at 02:03
  • Of course, this is only a win in terms of retrieving resources. A POST, PUT, DELETE, etc. will not be cached. Also, there's a dependency on how fresh the data need to be. Caching will be of little benefit if the data need to be accurate, literally, up to the minute. – John Saunders Aug 20 '09 at 02:11
1

My client (major carrier) actually ran a performance test on REST vs SOAP access to their API's and found the difference was almost non-existent. XML parsers are pretty quick these days and aside from that, there isn't much actual overhead when using SOAP. The contract (WSDL) with all it's rules and specifications is something that comes into play when a client program is being written or updated, not so much in the scope of a real-time exchange with an API.

wintermute
  • 121
  • 3
  • 9
0

Absent a clear requirement to the contrary, you should always prefer REST to SOAP. There are (rare) times when SOAP provides you with what you need (and those times will get more rare as REST improves, such as having a WADL standard), but in the general case, SOAP is just a whole lot of headache to get you where REST is already standing and waiting.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
Yishai
  • 90,445
  • 31
  • 189
  • 263
  • 3
    REST will not have a WADL or similar standard, since it is just an architecture. – aehlke Jul 20 '09 at 19:46
  • WADL already exists, so it seems kind of late to argue that REST won't have a WADL standard. It just remains to be seen how popular it will be. The fact of the matter is a standardized way of knowing what parameters you can send to a REST service and what you get back is useful. Until that exists in REST, SOAP and WSDLs will fill that gap. Of course, many REST services won't fit with a WADL or employ one, but that isn't the same thing. – Yishai Aug 26 '09 at 14:36
  • Standardization makes NO sense for REST, since REST is an architectural style, not a specific technology or protocol. The fact that there will never be a standard for REST is BY DESIGN. Fielding himself says this. I think you misunderstand REST and architecture in general. – aehlke Aug 27 '09 at 17:30
  • I think that rather misses the point. It is nice to try to argue some pure definition, but in fact REST has a de facto meaning and de facto standards. Perhaps you would prefer to say that in cases where you need a defined protocol, SOAP is the better choice, but to my thinking REST is developing de facto protocols, even if Fielding didn't imagine it. – Yishai Aug 27 '09 at 18:23
  • Yishai, you'll have to elaborate, since I can't see a reason to agree with that. There are varying implementations of REST, there is not one specific valid type of implementation. – aehlke Aug 27 '09 at 22:47
0

To directly answer your question, I'd say yes. REST is usually regarded as the lighter alternative. Also, at the current stage, REST is still consider/practiced by many to be more of a "direction/guideline" then a full protocol.

There's an interesting article depicting their differences in an interesting dialogue.

Personally, I'd say REST should be pretty much better than SOAP in all cases a normal person would choose. On the other hand, designing a true REST architecture requires a lot of planning and considerations. Most attempts fail at that and become STREST (mentioned in the above article), which is like mixing SOAP and REST and losing some of the benefits REST provides.

kizzx2
  • 18,775
  • 14
  • 76
  • 83
-1

REST will almost always be faster since there's less processing and smaller envelopes.

pbreitenbach
  • 11,261
  • 3
  • 33
  • 24