REST vs SOAP: What Are the Key Differences?

TL;DR

SOAP is a standardized protocol with predefined rules, while REST is an architectural style with loose guidelines. SOAP is function driven, works only with XML, and runs over HTTP, SMTP, UDP and others; REST is data driven, supports plain text, HTML, XML, JSON and YML, and works only on HTTP. REST calls can be cached and use fewer resources; SOAP adds WS-Security and ACID compliance.

Transcript

the age-old question is what is the difference between soap and rest apis and which one is right for my project the two most famous web services that is available today is soap and rest so if you're looking for a resource that provides you with an answer to this age-old question you've come to the right place hi all welcome to the session on rest v... Read More

Key Insights

• SOAP is a standardized protocol with predefined rules to follow, whereas REST is an architectural style with loose guidelines and recommendations. This design difference is the root of most other contrasts between the two, including message format rigidity and how tightly clients and servers are coupled.
• SOAP is function driven, meaning data is made available as services, such as a getUser operation. REST is data driven, meaning data is made available as resources. This distinction shapes how developers model an API and how consumers address what they need.
• SOAP is stateless by default but can be made stateful, while REST is stateless with no server side sessions occurring. When an application must carry state from one request to another, the SOAP standard provides the WS structure to support that requirement.
• SOAP API calls cannot be cached, whereas REST API calls can be cached. Caching stores the results of the most frequent queries in an intermediate location, so a client checks the cache first and skips the trip to the server when the resource already exists there.
• SOAP offers WS-Security with SSL support plus built-in ACID compliance, where ACID stands for atomicity, consistency, isolation and durability. WS-AtomicTransactions give enterprise grade transaction quality, which is one reason SOAP is still used for sensitive information in enterprise architecture. REST supports HTTPS and SSL.
• SOAP requires more bandwidth and computing power, which is where it falls behind, while REST requires very few resources. Because SOAP messages are heavier in content and consume far greater bandwidth, REST should be used wherever network bandwidth is a constraint.
• SOAP works only on an XML based messaging protocol, making it an application of the XML specification. REST can take several formats including plain text, HTML, XML, JSON and YML. On transfer protocol, SOAP works on HTTP, SMTP, UDP and others while REST works only on HTTP.
• The WSDL document is SOAP's key challenge because it creates a tight contract between client and server. It lists every operation and data type in the SOAP messages, so renaming a message forces all currently connected clients to change their code to accommodate it.

Questions & Answers

Q: What is the difference between SOAP and REST?

SOAP is a standardized protocol with predefined rules, while REST is an architectural style with loose guidelines and recommendations. SOAP is function driven with data available as services; REST is data driven with data available as resources. SOAP is stateless by default but can be made stateful, and its calls cannot be cached; REST is stateless with no server side sessions and its calls can be cached. SOAP only uses XML and works on HTTP, SMTP, UDP and others, while REST supports plain text, HTML, XML, JSON and YML but works only on HTTP.

Q: What does SOAP stand for and what was it designed for?

SOAP stands for Simple Object Access Protocol. It is a protocol that was designed well before REST came into the picture. The main idea behind designing SOAP was to ensure that programs built on different platforms and programming languages, such as Java, HTML and Python, could exchange data in a very easy manner. More precisely, SOAP is a messaging protocol specification for exchanging structured information, that is data, in the implementation of web services and computer networks.

Q: What is a RESTful web service and which HTTP verbs does it use?

REST stands for Representational State Transfer, and any web service defined on the principles of REST can be called a RESTful web service. REST was designed specifically for working with components such as media components, files, or even objects on a particular hardware device. A RESTful web service uses the normal HTTP verbs GET, POST, PUT and DELETE to work with the required components. A REST API is an application programming interface that conforms to the constraints of the REST architectural style and allows interaction with RESTful web services.

Q: When should you use REST instead of SOAP?

REST should be used in several scenarios. First, where there are limited resources and bandwidth, since SOAP messages are heavier in content and consume far greater bandwidth. Second, for statelessness, when there is no need to maintain a state of information from one request to another. Third, for caching, when many requests need to be cached so frequent query results can be stored in an intermediate location and reduce trips to the server. Fourth, when ease of coding matters, because coding REST services and their implementation is far easier than SOAP, making REST the way to go for a quick win solution.

Q: When should you use SOAP instead of REST?

SOAP can be used when there is a need for asynchronous processing and subsequent invocation, where the client needs a guaranteed level of reliability and security, since the SOAP 1.2 standard and above provides additional features especially around security. SOAP also suits a formal means of communication, where both client and server agree on the exchange format and SOAP gives rigid specifications for that interaction. Finally, SOAP fits stateful operations, because when state must be maintained from one request to another the SOAP standard provides the WS structure to support that requirement.

Q: Why is SOAP considered more secure than REST?

SOAP has WS-Security with SSL support and built-in ACID compliance. ACID stands for atomicity, consistency, isolation and durability, which is an enterprise grade transaction quality. For example, if financial transactions must be very secure, WS-AtomicTransactions that are ACID compliant can be applied. ACID compliance is one of the reasons SOAP is still used when exchanging sensitive information in enterprise architecture. REST, by contrast, supports HTTPS and SSL but does not impose any sort of security the way SOAP does, which is why REST is described as the worst mechanism for confidential data passed between client and server.

Q: What are the main challenges of using a SOAP API?

One key challenge is the WSDL document itself. The WSDL tells the client all the operations the web service can perform and contains information such as the data types used in the SOAP messages. If the WSDL file changes as per business requirements, for example if a message name changes, then all clients currently connecting to the web service must make the corresponding change in their code. This tight contract between client and server means one change can have a large impact on all client applications. The other key challenge is the size of the SOAP messages transferred from client to server, which is a big issue where bandwidth is constrained.

Q: Which types of applications is SOAP recommended for versus REST?

SOAP is recommended for enterprise applications, high security applications, distributed environments, financial services, payment gateways and telecommunication services. REST is recommended for public APIs, web services, mobile services and social networks. The split follows from their strengths: SOAP brings WS-Security, ACID compliance and rigid formal contracts suited to sensitive enterprise exchanges, while REST is lighter on bandwidth and computing power, easier to code, and cacheable, which suits publicly available URLs and high volume consumer facing services.

Summary & Key Takeaways

• SOAP stands for Simple Object Access Protocol and was designed well before REST appeared. Its main purpose was to let programs built on different platforms and programming languages, such as Java, HTML and Python, exchange data easily. It is a messaging protocol specification for exchanging structured information in the implementation of web services and computer networks.

• REST stands for Representational State Transfer and was designed for working with components such as media components, files, or objects on a particular hardware device. Any web service defined on REST principles is a RESTful web service, and it uses the normal HTTP verbs GET, POST, PUT and DELETE to work with the required components.

• The differences span design, approach, statefulness, caching, security, performance, message format and transfer protocol. SOAP is recommended for enterprise applications, high security applications, distributed environments, financial services, payment gateways and telecommunication services, while REST is recommended for public APIs, web services, mobile services and social networks.

• REST fits scenarios with limited resources and bandwidth, no need to maintain state between requests, heavy caching needs, and where ease of coding matters. SOAP fits asynchronous processing and subsequent invocation, guaranteed reliability and security, formal means of communication with an agreed exchange format, and stateful operations via the WS structure.

• Both technologies carry challenges. SOAP's WSDL document creates a tight contract between client and server, so one change forces every connected client to update its code, and SOAP messages are large. REST's biggest challenge is the lack of security, since it imposes no security mechanism the way SOAP does.