REST Web Services and SOAP Web Services have been compared for a long time and both architectures have their blind-supporters. The best way to decide which to use is by looking at the needs of a service. These needs may be various and there can be drawbacks or advantages of each one of them. We are going to compare both of them to clarify which use cases they are best at.
When it comes to deciding whether SOAP Web Services or REST Web Services to be used, the first thing helps us decide is the scale and the domain of the concerned application. SOAP Web Services is suitable for enterprise scale, possibly decentralized and security-demanding applications, occasionally accepting asynchronous requests. Also, the same SOAP message can be sent through various middleware systems. Researchers compare nine different decisions of conceptual decisions, which are; integration style, contract design, resource identification, URI design, resource interaction, semantics resource relationships, data representation/modeling, message exchange patterns, and service operations enumeration. While RESTful services require a designer to make eight of these decisions, it is only five for WS-*, Researchers again identify ten technologies that are relevant to both styles; transport protocol, payload format, service identification, service description, reliability, security, transactions, service composition, service discovery, and implementation technology. WS-* offer many more alternatives than RESTful services. Also, SOAP is supported by major software platforms, which transforms any Java or C# interface into a SOAP interface and generate required WSDL Documents. “The generated services conform to the Web Service standards defined by W3C”.
REST Web Services comes to mind when there are not much security concerns and there is a need for performance and speed. Especially mobile applications are more suitable for REST than SOAP, since creating a REST request message is 10 times faster and requires 8 times less memory than creating a SOAP request message on mobile mediums where resources are scarce and performance is a requirement. Also a SOAP message is significantly bigger than a REST message and this can cause bandwidth problems, due to having a body and header parts. REST is faster and lighter because REST is on HTTP protocol, whereas SOAP is protocol independent. Also REST applications are more flexible by transmitting response as XML, JSON and even plain-text, whereas SOAP only communicates through XML (Extended Markup Language).
Development for REST Services may be with ease, since REST Services support development without a premade client, instead can be accessed through web browsers and other application which can send HTTP requests. Also when developing and publishing Web services on the web, using the REST approach would be more suitable for maintenance costs reasons.
“A recent study  compared SOAP with REST to find out how many lines of code are needed to ensure the same functionality. In order to develop a REST service, there were 4016 lines of code written. In turn, to develop a SOAP service, there were 3844 lines of code written. Accordingly, in order to implement the REST client, there were 1117 lines of code written, and to realize SOAP client there were 509 lines of code written.” 
By returning a response from Web service, we can measure the execution speed objectively. Response times of SOAP and REST approaches are compared with each other by University of Florida students , of A SOAP client which selector adds data to the database makes a request. Result of response times was measured. Same applied for REST service. As a result, REST has shorter response times and better data throughput than the SOAP protocol. Also in a study where data is taken from a database of REST and SOAP services consecutively; memory usage and elapsed time of fetching are shown in table 1 and figure 1 and 2.
and data throughput of REST and SOAP services shown in table 2.
.This implies, also as seen in , that SOAP is not suitable for slow data transfer speeds or networks with large loads. Also, another measurement was made of a simple client-server scenario. The steps are (1)creating a user, (2) saving user message, (3) fetch user messages and (4) deleting that user. Measurement shows SOAP-XML service processing time is 4–5 times higher compared to the REST approach. (Fig 3.)
Having basic HTTP operations of GET, PUT, POST and DELETE, REST Web services are more “Web-friendly” since REST Web services are using Web architectural style closely related to HTTP. Being based on W3C and IETF standards such as HTTP, XML, URI and MIME; REST approach is simpler. Also, port 80 and 443 are usually open in most firewall configurations, which lets HTTP and HTTPS function without extended effort. On the other hand, SOAP uses an XML schema to define the data model, depends on data structures and APIs specified in WSDL (Web Service Definition Language) files, occasionally using other standards as WSBPEL, etc.
One of the constraints of REST protocol is caching. REST having caching, clustering and load balancing mechanisms, ensuring that REST server can be used under heavy load (such as a large number of simultaneous users) because REST protocol possibly uses a lightweight data format, such as JSON or even plain-text. This reduces server load.
Some IDEs, such as Eclipse, lets you import a SOAP WSDL file and generate client-side code automatically. This significantly reduces errors since it removes human-factor largely. But REST is more error-prone since the client-code must be handmade. SOAP has built-in error handling mechanisms, which helps to be more error-proof. In a study,the University of Sao Paulo reduced the number of errors by using a WSDL file.
Even though REST is using HTTPS occasionally, SOAP still has an advantage over REST in terms of reliability. WS-Security in the SOAP protocol is used one of the standards for signing and encrypting messages which makes data transfer safer. On the REST side, HTTP and HTTPS have built-in security mechanisms (recent implementations of TLS 1.3 makes HTTPS safer), additional security on demand can be manually implemented. TLS (Transport Layer Security) offers point-to-point encryption, but if there are mobile devices involved communication suffers because TLS channel must be frequently reset which means REST protocol may be superior performance-wise but there is a trade-off of reliability.
- Juris Tihomirovs, Janis Grabis. “Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics”, page 4, Memory section
- Juris Tihomirovs, Janis Grabis. “Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics”, page 3, C.Lines of Code section
- Juris Tihomirovs, Janis Grabis. “Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics”, page 3, D. Execution speed
- P. K. Potti, S. Ahuja, K. Umapathy, Z. Prodanoff, “Comparing Performance of Web Service Interaction Styles: SOAP vs. REST,” in Proceedings of the Conference on Information Systems Applied Research, New Orleans Louisiana, 2012, ISSN 2167–1508.
- J. Kangasharju, S. Tarkoma and K. Raatikainen, “Comparing SOAP performance for various encodings, protocols, and connections,”in Personal Wireless Communications (Lecture Notes in Computer Science (LNCS)). Springer-Verlag, vol. 2775, 2003, pp. 397–40
- Agon Memeti,Florinda Imeri,Betim Cico. “REST vs. SOAP: Choosing the best web service while developing in-house web applications”, page 4
- Einar Landre, Harald Wesenberg.”REST versus SOAP as Architectural Style for Web Services”, page 5
- Juris Tihomirovs, Janis Grabis. “Comparison of SOAP and REST Based Web Services Using Software Evaluation Metrics”, page 4, F. Errors Section
- T. Aihkisalo and T. Paaso, “Latencies of Service Invocation and Processing of the REST and SOAP Web Service Interfaces,” in 2012 IEEE 8th World Congress on Services, Honolulu, HI, 2012, pp. 100–107. https://doi.org/10.1109/SERVICES.2012.55
- Lawrence Muchemi. “Comparative Study of Rest and Soap: A Case Study of Registrar of Political Parties in Kenya” pages 6–8