REST vs SOAP

[OscarN]

Hey everyone, I am new to ServiceNow and learning integrations.

I get that REST uses JSON and SOAP uses XML, but not sure when SOAP is actually used in real projects since REST seems easier.

Do people still use SOAP a lot? In what cases?

Thanks!

[abirakundu23 · Accepted solution]

Hi @OscarN ,
Welcome to ServiceNow Ecosystem & best wishes for learning journey !
Please go through ServiceNow official Doc : https://www.servicenow.com/docs/r/xanadu/api-reference/web-services/c_APIAnalytics.html

REST and SOAP APIs are used for Servicenow integrations.

SOAP's Features :
However, SOAP-based APIs are considered more traditional and are less commonly used in modern architectures. SOAP relies on XML, resulting in larger payloads that can be more time-consuming to process hence, less Performance  and it is more secure.

REST Features :
Modern Architecture either use REST based or Scripted API or Integration Hub or Workflow data Fabric. 
REST relies on JSON/XML/text , smaller payloads , light weight that can be less time-consuming to process hence, faster , light weight and it is less secure than SOAP.

Use Cases :

SOAP :- Use for legacy system integration on premise environment like SAP, mainframe  IBM etc. For high security require for authentication then require. WSDL based contracts. Complex financial oriented integration require

REST :- Use for Modern platform like Jira, Adobe, Docu Sign, bi directional integration b/w 2 different system or Spoke based integration. Use Table API's for CRUD operations. Implement custom base integration which is not OOB supported use scripted REST API.

Community Articles: https://www.servicenow.com/community/developer-forum/what-is-difference-between-between-rest-and-soa...

Please mark helpful and correct answer if it's worthy for you.

[vaishali231]

hey @OscarN 

REST is generally preferred because it’s lightweight, easier to work with, and fits well with modern web/mobile architectures. However, SOAP continues to be relevant in the following cases:

1. Legacy system integrations
   Many enterprise systems (ERP, finance, older CRM platforms) were built using SOAP. Replacing them is costly, so integrations still rely on existing SOAP web services.
2. Strong security and compliance requirements
   SOAP supports standards like WS-Security, which provide built-in mechanisms for encryption, signatures, and secure message exchange. This is often required in banking, healthcare, or government use cases.
3. Strict contracts (WSDL-based integrations)
   SOAP uses WSDL to define a fixed contract between systems. This is useful in large enterprise environments where both sides need a clearly defined and stable interface.
4. Reliable messaging / transactional needs
   SOAP supports additional standards for guaranteed delivery and transaction handling, which can be important in financial or order-processing systems.

From a ServiceNow perspective:

• REST is typically used for modern integrations due to simplicity and flexibility.
• SOAP is still used when integrating with legacy systems or when the external system only exposes SOAP endpoints. 

*************************************************************************************************************************************

If this response helps, please mark it as Accept as Solution and Helpful.

Doing so helps others in the community and encourages me to keep contributing.

Regards

Vaishali Singh

[vaishali231]

hey @OscarN 

Hope you are doing well.

Did my previous reply answer your question?

If it was helpful, please mark it as correct ✓ and close the thread . This will help other readers find the solution more easily.

Regards,
Vaishali Singh

[Tanushree Maiti]

REST dominates modern web development over SOAP But SOAP remains a critical standard in specific high-stakes environments.

Many established ERP and CRM platforms, such as SAP etc, were built on SOAP. In these cases, it is often more cost-effective to continue using existing, stable SOAP integrations than to rebuild them in REST.

So in my client instances, all SAP projects still using Soap.

SOAP is often preferred for processing secure transactions because of its built-in WS-Security standards (in its header) and ACID compliance, which ensures that complex, multi-step transactions either succeed entirely or fail without partial data corruption.