REST Versus SOAP in Modern Enterprise Systems: A Structured Literature Review

Abstract

The evolution of modern enterprise architecture has been strongly influenced by distributed web services, especially protocol-based standards such as Simple Object Access Protocol (SOAP) and resource-oriented architectural styles such as Representational State Transfer (REST). Cloud-native ecosystems, microservice architectures, and public API management commonly favor the lightweight, JSON-compatible, and horizontally scalable characteristics of RESTful services, whereas legacy configurations and highly regulated environments continue to use SOAP because of its formal contracts and compatibility with WS-* specifications for message-level security, reliable messaging, and transaction coordination. This paper presents a structured literature review that evaluates the architectural trade-offs, performance patterns, security boundaries, reliability considerations, and enterprise use cases of REST and SOAP. The review follows PRISMA-informed reporting practices and software-engineering review guidance, but it is not presented as an exhaustive systematic review because the original search strategy required REST and SOAP terms to appear together. IEEE Xplore, ACM Digital Library, ScienceDirect, and Scopus were searched for studies published between 2021 and 2026, resulting in 32 selected studies. The selected literature contains different evidence roles, including direct REST-SOAP empirical comparisons, REST-only and SOAP-only empirical studies, implementation studies, analytical papers, surveys, reviews, and contextual technical sources. The synthesis therefore separates direct empirical evidence from contextual and secondary evidence. The findings indicate that RESTful APIs generally show lower latency, smaller payloads, simpler parsing, and better horizontal scalability in the reported benchmark and web-facing settings, while SOAP remains relevant where formal service contracts, message-level protection, reliable messaging patterns, and transaction coordination are required. The paper identifies gaps in production-representative stress testing, empirical security comparison, reference-level traceability, and independent validation of hybrid REST-SOAP decision models. The resulting decision framework is presented as a provisional evidence-informed decision aid, not as an empirically validated tool.

1. Introduction

The rapid development of enterprise systems can be attributed to the increased need for scalable, interoperable, and distributed computing solutions. Web services represent the components used in connecting various heterogeneous systems and provide the foundation for service-oriented architecture (SOA) and modern applications ecosystems. There are mainly two approaches employed in this area: SOAP and REST. SOAP refers to a protocol-based standard that uses XML messaging and service description formats like WSDL.

REST, on the contrary, can be termed as an architectural pattern, which incorporates the use of HTTP protocols together with principles of resource-based design as far as the provision of flexibility and simplicity to the service users is concerned [1]. In the last ten years, there has been a shift in the paradigm where service-based applications have moved towards RESTful APIs especially due to the emergence of technologies like cloud computing, microservice architecture, and API-driven software development. REST is, in this regard, considered to be the most popular for web service delivery due to the lightweight nature of the protocol along with being compatible with web technologies. However, the use of SOAP messaging protocols is made within organizations, mainly for the purpose of creating a high level of security, reliability, and transactional integrity using mechanisms like WS-Security and WSDL [2].

1.1. Importance of the Study

It is crucial to recognize the distinction between REST and SOAP when designing and developing enterprise-level systems. The choice of either technique plays an essential role in deciding the basic features of any system, including performance, scalability, security, interoperability, and maintainability. Contemporary enterprise applications, particularly those built using microservices architecture, require light-weight messaging services that enable quick scalability and interconnection. REST addresses performance and scalability concerns through statelessness and lightweight data; security and transactions require additional measures. On the other hand, applications such as financial institutions, health care providers, and government organizations need to be highly compliant and secure enough to deliver messages, while the use of SOAP-based services would be an added advantage. Moreover, considering the integration of various architectural components by large corporations using the advantages offered by existing and evolving technology, it would be imperative to evaluate the time and circumstances under which REST or SOAP should be utilized to ensure the effectiveness and sustainability of the systems. In this case, it becomes vital for both scholars and practitioners to undertake an overall evaluation of the technologies.

1.2. Scope of the Review

This study focuses on a structured literature review of research comparing REST and SOAP in modern enterprise systems. The review includes 32 selected studies published between 2021 and 2026, covering contemporary technology trends such as cloud computing, microservices, API gateways, and hybrid enterprise integration. The analysis is limited to studies that examine web services within enterprise, SOA, cloud, microservice, or large-scale system contexts. Because the selected literature contains heterogeneous evidence types, this review distinguishes direct empirical REST-SOAP comparisons from REST-only or SOAP-only empirical studies, secondary reviews, analytical studies, and contextual technical sources. This distinction is used throughout the synthesis so that broad conclusions are not supported only by contextual evidence.

• Performance and efficiency
• Scalability and flexibility
• Security and reliability
• Interoperability and integration
• Maintainability and usability

It is also interesting to explore practical applications of these technologies in SOA, microservices, and web-based systems, while excluding unrelated domains such as purely theoretical models or non-enterprise applications.

1.3. Need for the Review

Despite such an extensive study of REST and SOAP, the existing studies usually address particular aspects of the system, such as performance or security, without providing a general comparative analysis of various assessment factors. In addition, most studies are either outdated or ignore new approaches, such as microservices architectures, API gateways, and cloud-based systems. Moreover, lack of commonly used assessment models and lack of standardized assessment methods are some of the issues related to review articles, while inability to come up with one conclusion in each case hinders a uniform assessment.

Existing Reviews	Limitation	Gap
Earlier REST vs. SOAP studies	Focused mainly on performance/security	No enterprise-wide synthesis
Web service studies	Pre-cloud era	Limited microservices context
API studies	Examine REST only	Lack SOAP comparison
Service composition reviews	Ignore hybrid ecosystems	Missing modern architecture evidence

This review differs from earlier REST-SOAP comparisons in four ways. First, it focuses on the 2021–2026 period to capture recent enterprise integration, cloud-native, API governance, and hybrid architecture concerns. Second, it compares REST and SOAP across architecture, performance, scalability, security, reliability, interoperability, maintainability, and use-case suitability rather than focusing only on speed or message format. Third, it explicitly classifies the evidence role of each selected study, so direct empirical findings are distinguished from secondary reviews, analytical papers, and contextual technical sources. Fourth, it develops a provisional evidence-informed decision framework for REST, SOAP, or hybrid selection while clearly acknowledging that the framework has not yet been independently validated by practitioners.

The remainder of this paper is organized as follows. Section 2 provides the background; Section 3 details the structured review method; Section 4 discusses the results addressing the research questions; and Section 5 concludes the paper.

2. Background

Web services constitute the fundamental layer of contemporary enterprise systems, which provide a means for heterogeneous applications to interact with one another in a seamless manner despite being distributed across different platforms and programming languages. Contemporary enterprise systems are not monoliths; rather, they are loosely connected components that need to exchange data with each other efficiently. This has brought into focus the importance of developing applications using a Service Oriented Approach, wherein applications are implemented as a set of autonomous services that share data through well-defined interfaces and protocols. The primary objective of SOA is to facilitate reuse, scalability, interoperability, and integration.

In such an architecture, web services form the mode of communication within the architecture, mainly through technologies such as SOAP, WSDL, UDDI, and REST-based APIs. Such technologies play a role in allowing the service providers to expose functionalities, thus enabling discovery and usage by other systems, leading to a network of interlinked services. Increasing complexity in corporate environments necessitates effective communication in services, especially when dealing with cloud computing, microservices, and application programming interfaces (APIs). In such environments, there is a need to cater for high capacity, effective data transfer, and improved performance of the system. REST and SOAP are the two popular architectures in web services. SOAP is an approach that is extremely standardizable and protocol-based, where security and reliability have been the two main aspects, making SOAP also very much suited for mission-critical enterprise-level applications that often need SOAP for their communications purposes. On the other hand, REST is a highly flexible and scalable architectural model, which is more aligned with the modern web technologies, and therefore makes distributed communications between these disparate systems effective in terms of their consumption. Both models are applicable to enterprise-level systems due to varied use cases. For good enterprise architecture, it is critical to know the basic principles, strengths and weaknesses of REST and SOAP to design effective enterprise architecture. As such, two examples of these approaches are analyzed in this section. Accordingly, a deep knowledge and context of both approaches is covered as a guide to facilitate the comparison in the following sections of the comparative analysis offered in the subsequent sections.

2.1. Representational State Transfer

REST (Representational State Transfer) is an architectural style for developing web services through widely used web technology, including HTTP and URI. It is an architectural style that consists of some constraints which emphasize that statelessness, client-server, uniform interface, and cache ability improve the scalability and efficiency of the system. Resources in the REST architectural style are identified through URIs and utilized with HTTP methods. It makes communication easier since the operation works based on how the web works. On the other hand, RESTful API uses lightweight data format such as JSON, and it allows the data to flow efficiently than those that use XML data format [1,3,4,5].

REST has become the prevailing architectural pattern adopted in web-based services, especially those implemented on microservices and cloud-native platforms. Stateless nature allows scaling horizontally, which becomes an evident factor in the case of highly loaded environments. In addition, the architecture provides loose coupling among services, thus enabling independent development and deployment of their code. As REST lacks rigorous guidelines for implementation, there are problems with designing and using APIs. According to the reviewed literature, the use of poorly designed RESTful APIs results in poor comprehensibility of applications and can increase complexity of integration. However, REST is still popular nowadays. The reason for that is its flexibility, simplicity, and compatibility with modern web-based technologies [3].

2.2. Simple Object Access Protocol

SOAP (Simple Object Access Protocol) is a protocol-based standard designed for exchanging structured information between systems in a network. It relies on XML messaging and operates through a well-defined structure consisting of an envelope, header, and body. SOAP services are typically described using Web Services Description Language (WSDL), which defines the service interface and communication rules in a formal and machine-readable format. SOAP plays a critical role in traditional Service-Oriented Architecture (SOA), where it facilitates communication between services using standardized protocols such as WSDL and UDDI. Its strong emphasis on standardization ensures interoperability across platforms and programming languages, making it suitable for enterprise environments. One of SOAP’s major advantages is its support for advanced specifications, including:

• WS-Security for message-level security
• WS-ReliableMessaging for reliable delivery patterns
• WS-Transaction for transactional consistency

For this reason, SOAP may be appropriate in applications such as financial and government systems when reliable, secure, and transactional communication is required. At the same time, SOAP is characterized by greater complexity and higher performance costs because of XML messaging and adherence to protocol rules. The SOAP request is typically larger than a REST request and requires additional processing, which may affect performance under high loads. In addition, the SOAP structure can be less flexible for current web and mobile application development.

3. Structured Literature Review

This structured literature review uses a systematic search, screening, and narrative synthesis process informed by PRISMA 2020 reporting principles and software-engineering SLR guidance from Kitchenham and Charters. Because the search strategy was centered on records containing both REST and SOAP terms, the revised manuscript is framed as a structured literature review rather than an exhaustive systematic literature review. A review protocol was developed before study selection to improve consistency. The protocol specified research questions, search strategy, eligibility criteria, data extraction procedures, quality assessment criteria, risk-of-bias dimensions, and synthesis methods. The protocol was not registered in an external repository; this limitation is reported in the Discussion [6,7].

• Identification—Relevant studies were collected from academic databases using predefined keywords such as REST, SOAP, web services, SOA, and enterprise systems.
• Screening—Duplicate and irrelevant studies were removed based on titles and abstracts.
• Eligibility—Full-text articles were assessed using inclusion and exclusion criteria.
• Inclusion—A final set of 32 selected studies was retained for detailed analysis. These studies were classified by evidence role so that primary empirical findings, secondary reviews, analytical papers, and contextual technical sources could be interpreted appropriately.

The selected studies focus on enterprise-level applications and related modern architectures such as microservices, cloud computing, API management, SOA, and web-based systems. Peer-reviewed journal and conference papers were prioritized. Studies with empirical, comparative, analytical, or systematic findings were included only when they were directly relevant to REST, SOAP, or enterprise web-service integration.

Use of AI-assisted visual generation: AI assistance was used only to generate and refine the visual layout of Figure 1, Figure 2 and Figure 3. The authors provided the conceptual content, including the REST, SOAP, client, server, service registry, WSDL, UDDI, and enterprise-system components. The authors manually reviewed and edited the figures to ensure that the diagrams were consistent with the terminology and explanations used in the manuscript. No empirical data, search results, study selection decisions, analysis, findings, or conclusions were generated by the AI tool.

3.1. Review Protocol and Research Questions

A review protocol was developed before the study selection process to reduce methodological bias and improve consistency. The protocol defined research questions, search strategy, inclusion and exclusion criteria, data extraction procedures, quality assessment criteria, risk-of-bias assessment, and synthesis methods. The protocol was not formally registered in an external repository. In response to review feedback, the revised manuscript explicitly distinguishes protocol-based planning from formal protocol registration and clarifies that the study is a structured literature review with narrative synthesis rather than a fully exhaustive systematic review. The objective of this research is to analyze and compare REST and SOAP web service architectures in modern enterprise systems, focusing on their performance, scalability, security, reliability, interoperability, maintainability, and applicability across different domains.

• Search strategy and keywords
• Inclusion and exclusion criteria
• Data extraction and synthesis methods

Based on this protocol, the following research questions (RQs) were formulated to guide the study in

Table 1. Research Questions and Motivations.

RQ No.	Research Question	Motivation
RQ1	What are the key architectural differences between REST and SOAP in enterprise systems?	To understand the fundamental design principles and how they influence system behaviour and implementation.
RQ2	How do REST and SOAP compare in terms of performance and scalability?	To evaluate which approach is more suitable for modern high-demand environments such as cloud and microservices.
RQ3	How do REST and SOAP differ in terms of security and reliability?	To assess their suitability for critical enterprise applications requiring secure and reliable communication.
RQ4	In what scenarios or use cases is REST or SOAP more appropriate in enterprise systems?	To provide practical guidance for selecting the appropriate technology based on system requirements.

below:

These research questions enable a comprehensive and structured comparison of REST and SOAP, ensuring that both theoretical and practical aspects are addressed. The findings derived from these questions form the basis for identifying trends, advantages, limitations, and research gaps in existing literature.

3.2. Search Strategy

A structured search strategy was designed to identify studies that directly discuss REST and SOAP in modern enterprise systems. The search aimed to retrieve comparative and enterprise-relevant literature, not every publication that discusses REST or SOAP separately. The search process used combinations of keywords, Boolean operators, and controlled variations in terms.

• REST
• RESTful APIs
• SOAP
• web services
• enterprise systems
• SOA
• cloud computing
• microservices

Boolean operators AND and OR were applied. Exact search syntax used in each database is provided in

Table 2. Search Strings for REST versus SOAP structured review.

Database	Search Parameter
IEEE Xplore	(“All Metadata”:REST OR “All Metadata”:RESTful) AND (“All Metadata”:SOAP) AND (“All Metadata”:“web services” OR “All Metadata”:API) AND (“All Metadata”:“enterprise systems” OR “All Metadata”:SOA OR “All Metadata”:microservices) Filters: Journals & Conference Papers, 2021–2026, English Language
ACM Digital Library	(Abstract:REST OR Abstract:“RESTful”) AND (Abstract:SOAP) AND (Abstract:“web services” OR Abstract:API) AND (Abstract:“enterprise systems” OR Abstract:SOA OR Abstract:microservices) Filters: Journals & Conference Papers, 2021–2026, English Language
ScienceDirect	TITLE-ABSTR-KEY(REST OR RESTful) AND TITLE-ABSTR-KEY(SOAP) AND TITLE-ABSTR-KEY(“web services” OR API) AND TITLE-ABSTR-KEY(“enterprise systems” OR SOA OR microservices) Filters: Journals & Conference Papers, 2021–2026, English Language
Scopus	TITLE-ABS-KEY(REST OR RESTful) AND TITLE-ABS-KEY(SOAP) AND TITLE-ABS-KEY(“web services” OR API) AND TITLE-ABS-KEY(“enterprise systems” OR SOA OR microservices) Filters: Journals & Conference Papers, 2021–2026, English Language

. Two-stage pilot searches were conducted before final retrieval. The main search required REST and SOAP terms to appear together; therefore, the review is deliberately framed as a structured review of directly comparative and closely related evidence. The restriction is also reported as a limitation because it may miss high-quality single-technology studies that could inform comparative interpretation. Database searches were conducted between 20 April 2026 and 30 April 2026.

Database	Rationale
IEEE Xplore	software engineering
ACM DL	computing systems
Scopus	broad indexing
ScienceDirect	enterprise studies

The search was limited to studies published between 2021 and 2026 to capture recent developments in API design, cloud computing, and microservices architecture. Only peer-reviewed journal articles and conference papers written in English were considered. As illustrated in Table 2, the following search strings were customized to align with each platform’s search capabilities while maintaining consistency with the study objectives.

3.3. Inclusion and Exclusion Criteria

The inclusion and exclusion criteria (

Table 3. Selection Criteria for Studies.

Inclusion	Exclusion
Studies published between 2021 and 2026	Papers published before 2021
Written in English	Non-English Publication
Research focused on REST and/or SOAP web services	Studies not directly related to REST or SOAP
Papers discussing enterprise systems or SOA, or microservices	Studies not directly related to enterprise systems or SOA, or microservices
Peer-reviewed journal articles or conference papers	Duplicate or incomplete studies
Studies with empirical, comparative, or analytical findings	Short papers, editorials, or opinion-based articles

) were used to identify relevant studies from the initial search results. This is being done to ensure that research aligned with the objective of systematically reviewing REST versus SOAP would only be included. In particular, the selection was limited to articles published within the last 6 years to identify new trends and advancements. This temporal constraint allows us to include high-quality, relevant studies concentrating on REST and SOAP within this recent period.

3.4. Data Extraction and Data Items

Data extraction was conducted through a structured procedure to improve consistency and reliability across the 32 selected studies. A standardized electronic extraction form was used to record study characteristics, evidence role, architecture type, performance metrics, scalability indicators, security mechanisms, reliability and transaction support, application domain, communication format, limitations, and contribution to each research question. The extraction process also recorded whether a study provided direct empirical evidence, secondary review evidence, analytical evidence, or contextual technical evidence. This classification was added to prevent secondary or conceptual studies from being interpreted as primary empirical evidence.

• Publication year
• Study type (journal or conference paper)
• Application domain (e.g., enterprise systems, cloud, microservices)

Furthermore, to address heterogeneity among studies, data preparation and standardization techniques were applied. For example, performance metrics reported in different formats were normalized, and diverse evaluation criteria were grouped into common categories. This standardization enabled meaningful comparison and synthesis across studies.

Table 4. Summary of extracted data points and standardization methods.

No.	Data Item	Description of Data Points Extracted	Data Preparation and Standardization	Relevant RQ
1	Service Architecture	Type of web service used (REST, SOAP, or hybrid), architectural style (SOA, microservices).	Standardized into three categories: REST-based, SOAP-based, and Hybrid systems to unify classification.	RQ1
2	Performance Metrics	Metrics such as response time, latency, throughput, and resource utilization.	All values were normalized into comparable units (e.g., milliseconds, requests/sec) for consistency across studies.	RQ2
3	Scalability Factors	Indicators such as load handling, concurrency support, and system scalability bexhavior.	Grouped into High, Moderate, and Low scalability levels based on reported system performance under load.	RQ2
4	Security Mechanisms	Security features such as WS-Security, HTTPS, OAuth, authentication, and encryption methods.	Categorized into Protocol-level security (SOAP) and Transport-level security (REST) for comparison.	RQ3
5	Reliability and Transaction Support	Support for reliable messaging, fault tolerance, and transaction management.	Standardized into Supported and Not Supported, with notes on mechanisms (e.g., WS-Reliable Messaging).	RQ3
6	Application Domain	Domain of implementation (e.g., banking, healthcare, cloud systems, enterprise applications).	Grouped into common categories: Enterprise, Cloud/Microservices, and Web/Mobile applications.	RQ4
7	Communication Format	Data formats used (XML, JSON, others).	Standardized into XML-based (SOAP) and JSON/Lightweight formats (REST).	RQ1
8	Open Issues and Limitations	Reported challenges such as performance overhead, complexity, scalability issues, or security concerns.	Thematic analysis used to group issues into Performance, Security, Complexity, and Scalability challenges.	RQ4

summarizes the extracted data points, their corresponding standardization methods, and their relevance to the research questions.

3.5. Study Selection

The study selection process was conducted in multiple stages in accordance with PRISMA 2020 guidelines, the checklist of which can be found in the Supplementary Materials. During the search process across all four selected databases, a consistent publication date filter was applied to limit the results to studies published between 2021 and 2026. This period was selected because it would allow us to include the last emerging trends in research. Along with a broad date limitation, databases were searched using database specific settings and advanced search techniques to broaden the search in the interest of both sensitivity and specificity. Specific settings and filters applied for each database are presented in

Table 5. Summary of database search and hits.

Database	Database Specific Measures	Hits
IEEE Xplore [8]	(“All Metadata”:REST OR “All Metadata”:RESTful) AND (“All Metadata”:SOAP) AND (“All Metadata”:“web services” OR “All Metadata”:API) AND (“All Metadata”:“enterprise systems” OR “All Metadata”:SOA OR “All Metadata”:microservices) Filters: English Language, Journals & Conference Papers, 2021–2026	112
Scopus [9]	TITLE-ABS-KEY(REST OR RESTful) AND TITLE-ABS-KEY(SOAP) AND TITLE-ABS-KEY(“web services” OR API) AND TITLE-ABS-KEY(“enterprise systems” OR SOA OR microservices) Filters: English Language, Journals & Conference Papers, 2021–2026	80
ACM Digital Library [10]	(Abstract:REST OR Abstract:“RESTful”) AND (Abstract:SOAP) AND (Abstract:“web services” OR Abstract:API) AND (Abstract:“enterprise systems” OR Abstract:SOA OR Abstract:microservices) Filters: English Language, Journals & Conference Papers, 2021–2026	78
ScienceDirect [11]	TITLE-ABSTR-KEY(REST OR RESTful) AND TITLE-ABSTR-KEY(SOAP) AND TITLE-ABSTR-KEY(“web services” OR API) AND TITLE-ABSTR-KEY(“enterprise systems” OR SOA OR microservices) Filters: English Language, Journals & Conference Papers, 2021–2026	95
Total		365

.

Initial comprehensive search in the chosen databases retrieved a total of 365 possibly relevant records. Zotero (Version 7.0.1.5)reference-management software was used at all stages of the selection process to deal with references in an organized and effective way. Steps 1 to 5 were repeated for systematic search, filtration, and extraction of the relevant studies for quality assessment. This methodical process helped to maintain consistency, transparency, and traceability when selecting the papers. The detailed procedure of the selection process is as follows:

• Duplicate removal: As an initial step in refining the dataset, duplicate entries were removed using Zotero. A total of 35 duplicate records were identified and excluded, bringing the total number of unique records to 330 for title and abstract screening. Document type and relevance filtering were then applied separately to avoid conflating duplicate removal with eligibility screening.
• Field Screening: The keyword “SOAP, REST, Web service, Service-Oriented Architecture, microservices, enterprise system” was used to search in Zotero which screened the titles and abstracts to find relevant papers. After excluding 280 irrelevant records, the selection was narrowed down to 50 publications.
• Evidence-role screening: To address the mixed nature of the literature, full texts were classified by evidence role rather than excluded solely because the title contained words such as review, study, or report. Publications that were entirely secondary and did not contribute to the research questions were excluded. Secondary or review-oriented studies that were directly relevant to enterprise REST-SOAP interpretation were retained only as contextual evidence and were not treated as primary empirical studies.
• Exclusion Criteria 2 (EC2): 3 was insufficient technical data, reducing the count to 34 accessible papers from 37 papers.
• Exclusion Criteria 3 (EC3): Duplicate and low quality papers were excluded, resulting in the removal of 2 papers. This left 32 papers for further examination.

Figure 4 illustrates the flowchart of the selection process, outlining the structured approach used to narrow the initial pool of 365 records to 32 selected studies. The figure also clarifies that the final set includes different evidence roles rather than a single homogeneous set of primary empirical studies. This revision improves transparency and responds to the concern that secondary and analytical studies should not be treated as direct empirical evidence.

3.6. Quality Assessment Criteria

All selected studies were assessed using one consistent 0–9 quality scale. The assessment focused on objective and scope relevance, methodological transparency, evidence type and data support, comparability or benchmark fairness, and limitations or reproducibility. QA1 to QA4 were scored from 0 to 2, while QA5 was scored from 0 to 1. The criteria for assessing the quality across the 32 selected studies are outlined in

Table 6. Quality Assessment Criteria Framework.

Item	Assessment Criterion	Score	Description
QA1	Objective and scope relevance	0–2	0 = not relevant or unclear; 1 = partially relevant; 2 = directly relevant to REST, SOAP, web services, SOA, microservices, or enterprise integration.
QA2	Methodological transparency	0–2	0 = design, data source, tools, workload, participants, or analytical procedure not reported; 1 = partially reported; 2 = sufficiently reported to support interpretation.
QA3	Evidence type and data support	0–2	0 = claims are not supported by traceable evidence; 1 = partially supported by analytical or limited data; 2 = supported by empirical measurements, case data, survey/interview data, or clearly traceable analytical evidence.
QA4	Comparability and benchmark fairness	0–2	0 = comparison conditions are unclear or not comparable; 1 = partial comparability or limited benchmark detail; 2 = workloads, infrastructure, and measurement conditions are sufficiently comparable. For non-benchmark studies, the score reflects whether claims are appropriately bounded.
QA5	Limitations and reproducibility	0–1	0 = limitations, tools, data, or replication-relevant details are not adequately reported; 1 = limitations and reproducibility-relevant details are reported sufficiently for interpretation.
Total	Overall quality level	0–9	High = 8–9; Medium = 5–7; Limited = 0–4. This is the only quality-threshold scale used throughout the manuscript. Scores at the cut points are assigned exactly: 8 is High, 7 is Medium, 5 is Medium, and 4 is Limited. Limited studies are retained only for contextual interpretation, not as decisive evidence.

. A single threshold scale was used throughout the manuscript: High = 8–9, Medium = 5–7, and Limited = 0–4. Borderline cases were handled by applying the cut points exactly without rounding; therefore, a score of 7 remained Medium, a score of 8 was the minimum High score, a score of 5 was the minimum Medium score, and a score of 4 remained Limited. Limited quality studies were retained only for contextual interpretation and were not used as decisive evidence for major conclusions.

3.7. Quality Assessment Result

Based on the five criteria, each selected study was evaluated for research objective clarity, methodological robustness, evidence support, comparability, and limitations or reproducibility. The total score for each study was calculated by summing QA1 to QA5. The same threshold scale was applied consistently in the text, Table 6 and

Table 7. Quality Assessment Results.

Study Reference	QA1	QA2	QA3	QA4	QA5	Total	Quality Level
[1]	2	2	1	1	1	7	Medium
[2]	2	1	1	1	1	6	Medium
[3]	2	2	2	1	1	8	High
[4]	2	2	1	1	1	7	Medium
[5]	2	2	2	1	1	8	High
[12]	2	1	1	1	1	6	Medium
[13]	2	1	1	1	1	6	Medium
[14]	2	2	2	2	1	9	High
[15]	2	2	2	2	1	9	High
[16]	2	1	1	1	1	6	Medium
[17]	2	2	1	1	1	7	Medium
[18]	2	2	2	1	1	8	High
[19]	2	2	2	1	1	8	High
[20]	2	1	1	1	0	5	Medium
[21]	2	2	1	1	1	7	Medium
[22]	2	2	2	1	1	8	High
[23]	2	1	1	1	0	5	Medium
[24]	2	2	2	2	1	9	High
[25]	2	1	1	1	1	6	Medium
[26]	2	2	2	1	1	8	High
[27]	2	1	1	1	1	6	Medium
[28]	1	1	1	1	0	4	Limited
[29]	2	1	1	1	1	6	Medium
[30]	2	1	1	1	1	6	Medium
[31]	2	1	1	1	1	6	Medium
[32]	2	1	2	1	1	7	Medium
[33]	2	1	1	1	1	6	Medium
[34]	2	2	1	1	1	7	Medium
[35]	2	2	2	1	1	8	High
[36]	2	2	2	1	1	8	High
[37]	2	1	1	1	1	6	Medium
[38]	2	1	1	1	1	6	Medium

: High = 8–9, Medium = 5–7, and Limited = 0–4. No score was rounded to a higher category.

In borderline situations, the exact cut point determined the category; for example, 7 remained Medium, 8 was classified as High, 5 was classified as Medium, and 4 was classified as Limited. Studies rated High or Medium were eligible to inform the synthesis according to their evidence role. Studies rated Limited were retained only when they provided useful contextual information and were not used as decisive evidence for the main findings. The outcomes are shown in Table 7.

3.8. Bias Risk and Evidence Strength Integration

Risk of bias assessment was conducted to evaluate the credibility of the selected evidence and to determine how methodological limitations may influence the synthesis. Because the selected literature is heterogeneous, the assessment was not treated as a separate checklist only. Instead, each study was interpreted together with two linked classifications: (i) its evidence role, and (ii) its study level risk of bias judgement. This integration was used to decide how strongly each study could support the review conclusions.

The selected studies include direct REST-SOAP empirical comparisons, REST-only empirical studies, SOAP-only or SOAP-focused technical studies, implementation studies, analytical papers, secondary reviews, and contextual sources. Therefore, the review does not treat all selected publications as carrying equal evidential weight. Strong comparative conclusions, especially those concerning relative performance, scalability, maintainability, security, or reliability, are based primarily on direct REST-SOAP empirical comparisons. REST-only, SOAP-only, secondary, analytical, and contextual studies are used to support interpretation, explain mechanisms, or identify research gaps, but they are not used alone to establish comparative superiority.

The risk of bias assessment was used to qualify conclusions rather than mechanically exclude every study with limitations. Studies judged as low to moderate risk carry stronger interpretive weight than studies judged as moderate to high or high risk. Where evidence comes mainly from contextual, analytical, or secondary studies, the synthesis uses cautious language such as “suggests,” “indicates,” “is associated with,” or “helps explain.” Where direct comparative evidence is consistent across benchmark studies, the synthesis uses stronger but still bounded language such as “generally reported lower latency under tested conditions,” rather than universal claims such as “REST is always faster” or “SOAP is always more secure.”

Risk of bias dimensions were applied as follows:

• RB1: Selection bias: Assesses whether datasets, systems, experimental environments, participants, or application domains were selected using transparent and justified criteria.
• RB2: Publication or emphasis bias: Assesses whether the study reports only favourable outcomes, omits limitations, or appears to emphasise one architecture without sufficient balance.
• RB3: Benchmark or comparator bias: For comparative studies, assesses whether REST and SOAP were evaluated under equivalent workloads, infrastructure, tooling, and measurement conditions.
• RB4: Measurement bias: Assesses whether metrics such as response time, throughput, payload size, CPU usage, memory usage, security, reliability, or maintainability were measured using clear and consistent procedures.
• RB5: Reporting bias: Assesses whether the study reports enough methodological detail, limitations, and result information to support traceable interpretation.

Given the heterogeneous nature of the included studies, a structured evidence hierarchy was applied to guide data synthesis and interpretation. The evidence strength rules used in this study are presented in

Table 8. Evidence Strength Rules Used in the Synthesis.

Evidence Category	Examples of Supporting Studies	Permitted Use in Synthesis	Required Wording
Direct REST-SOAP empirical comparison	[4,14,15,19,22,32]	Primary basis for comparative conclusions about measured REST-SOAP performance, maintainability, and platform-specific behaviour.	Use bounded comparative wording, e.g., “REST generally reported lower latency in the tested benchmark settings.”
Single technology empirical evidence	REST-focused: [3,4,5,18,21,35]; SOAP-focused: [2]	Supports interpretation of design quality, usability, implementation practice, robustness, and technology-specific limitations. Not sufficient alone for REST-SOAP superiority claims.	Use contextual wording, e.g., “REST-only studies indicate design and governance issues that may affect maintainability.”
Implementation, migration, or case-based evidence	[4,26,32]	Supports practical use-case discussion, modernization paths, and hybrid REST-SOAP deployment interpretation.	Use setting-specific wording, e.g., “in the reported modernization setting.”
Analytical or contextual technical evidence	[12,13,16,25,27,29,30,31,33]	Explains architectural mechanisms, governance considerations, and enterprise context. Does not independently establish measured comparative effects.	Use interpretive wording, e.g., “helps explain why SOAP remains relevant.”
Secondary review, survey, or tertiary evidence	[1,17,20,23,34,37,38]	Used for background, triangulation, gap identification, and broader research context only.	Do not use as decisive evidence for direct REST-SOAP empirical claims.

.

As part of the evidence synthesis process, each conclusion was evaluated according to the quality, consistency, and type of supporting evidence. The impact of risk of bias and evidence roles on conclusion strength is summarized in

Table 9. How Risk of Bias and evidence role affected conclusion strength.

Conclusion Area	Main Evidence Used	Strength Assigned in This Review	Reason for Qualification
RQ1 Architectural differences	Primarily descriptive and analytical evidence, supported by direct comparison and implementation studies.	Moderate	REST and SOAP architectural differences are consistent across the literature, but much of the evidence is descriptive rather than experimentally measured.
RQ2 Performance and scalability	Direct REST-SOAP benchmarks and case/platform evidence, especially [14,15,19,24,32].	Low to moderate	Findings consistently favor REST in tested settings, but most data come from controlled or simplified benchmarks with limited production replication.
RQ3 Security and reliability	Mostly analytical/contextual evidence on WS-* standards plus SOAP-focused robustness evidence [2].	Low	The evidence supports standards-based capability, but there is limited direct empirical attack, fault-injection, or recovery comparison between REST and SOAP.
RQ4 Use-case suitability	Mixed evidence from comparative studies, implementation cases, analytical studies, and contextual reviews.	Moderate	Scenario mapping is consistent, but many use-case claims rely on contextual and analytical evidence rather than controlled enterprise deployment studies.
Decision framework	Synthesised from all evidence roles with greater weight assigned to direct empirical and implementation evidence.	Provisional	The framework is evidence in formed but not independently validated with practitioners or external enterprise cases.

.

4. Results

The following subsections address the four research questions defined in Section 3.1. The findings are drawn from the 32 selected studies that passed the final selection and quality-assessment stages. To address the heterogeneous evidence base, conclusions are explicitly separated by evidence strength. Direct REST-SOAP empirical comparisons are used for comparative performance claims. REST-only or SOAP-only empirical studies are used as contextual support for design, usability, implementation, and robustness. Secondary reviews and analytical papers are used to frame the enterprise context and do not independently establish comparative superiority.

Evidence labels used in this section: Measured values are values reported by direct benchmark, experiment, or platform studies; extracted study-level observations are quantitative figures reported by individual studies and not pooled; descriptive evidence counts show how many selected studies explicitly discuss a dimension and do not measure effectiveness; interpretive summaries combine mixed evidence roles and are used only for decision guidance.

Synthesis approach: The included studies use different methodologies, including controlled micro-benchmarks, implementation studies, production or platform case analyses, surveys, interviews, design studies, analytical papers, and secondary reviews. Statistical meta-analysis was not feasible because the studies do not share a common comparator, workload, deployment context, or measurement model. A narrative synthesis was therefore adopted. Evidence was grouped thematically by research question: architectural characteristics (RQ1), performance and scalability metrics (RQ2), security and reliability features (RQ3), and domain-specific use cases (RQ4).

Effect measures: No single statistical effect measure is applicable across all outcomes. Where individual studies report values such as response time, payload size, throughput, CPU use, or memory use, these figures are presented as reported by the original authors and are not pooled. Readers should interpret all numerical evidence as study-specific observations rather than meta-analytically derived estimates.

4.1. Research Question 1: What Are the Key Architectural Differences Between REST and SOAP in Enterprise Systems?

The key difference between the two technologies lies in the fact that SOAP stands for Simple Object Access Protocol, which is a messaging protocol standardized for exchanging structured information. REST, by contrast, is an architectural style based on the design principles of the World Wide Web [12,17]. This distinction leads to differences in message structure, coupling, interface design, state handling, transport assumptions, and security enforcement.

Philosophy of design and coupling: SOAP services are commonly described using a formal service contract written in the Web Services Description Language (WSDL). This contract can define operation names, data types, bindings, and communication rules in a machine-readable form [14,22,23,27]. Changes to the contract, such as modification of operation names or data types, may require corresponding client and service updates. This can create tighter coupling than RESTful approaches [22,24]. REST adopts a resource-oriented approach that uses a uniform interface, URIs, and standard HTTP methods. This looser coupling is well aligned with continuous delivery and independent deployment cycles in cloud-native development [16,26].

Message format and verbosity: The message exchanges under SOAP must always use XML as the message format. Each message is enclosed within a specific message envelope that consists of a header and body sections [12,14,23]. This level of detailing in the messages results in several disadvantages. First, the size of the message becomes bigger; this results in higher bandwidth usage. More importantly, message processing requires significantly more time from both sender and receiver [13,20,30]. The REST does not enforce strict message formats like SOAP. It allows JSON, XML, HTML, or even plaintext formats to be used [12,21]. Currently, JSON has emerged as the default data format used in RESTful APIs due to its concise nature and direct compatibility with JavaScript web environments [17,18,30].

HTTP requests and transfers: In REST, all operations map to HTTP verbs. GET requests fetch information, POST requests store new data, PUT requests modify data, and DELETE requests delete data. The protocol itself forms an integral component of the API design [12,15,20]. It is not the case with SOAP. Regardless of what the user wishes to do, all requests will be in the form of HTTP POST and the operation will be defined in the XML payload [12,19]. This feature has certain consequences on caching intermediaries and proxies. Such intermediaries will be able to intelligently process the RESTful GET request, but they cannot understand what lies inside the SOAP payload. On the other hand, SOAP does not care which transport is used. It is equally at home in SMTP or FTP besides HTTP [12]. In practice, however, HTTP wins.

State management: REST operates under a stateless constraint, meaning that each request should contain the information needed for the server to process it and that application session state should not be stored on the server between invocations [12,25,29,31]. This improves horizontal scalability because additional server nodes can be introduced without shared session coordination [13,21]. SOAP itself does not require services to be stateful; SOAP services may be designed as stateless or stateful depending on the application. In enterprise workflows, SOAP is often used with coordinated sessions or transaction-oriented interactions when multi-step operations require consistency, rollback, or reliable messaging [13,15]. Such designs can be useful in banking and regulated back-office processes, but they also increase scaling and operational complexity.

Caching: REST can use standard HTTP caching semantics, especially for cacheable GET responses [13,18,22,23]. This can reduce server processing under high request volumes. SOAP does not normally benefit from HTTP caching in the same way because operations are usually carried inside XML payloads, often sent through POST requests, and may depend on application context. This does not make caching impossible in every SOAP system, but it makes generic intermediary caching less straightforward than in RESTful designs [13,21,27,33].

Security mechanisms: SOAP can be used with WS-Security to protect message content through mechanisms such as encryption, digital signatures, and authentication tokens that are carried with the message rather than only with the transport channel [14,27]. Other WS-* specifications, such as WS-ReliableMessaging and WS-Transaction, can support reliable messaging patterns and transaction coordination when implemented in compatible environments [14,27]. REST commonly relies on HTTPS/TLS for channel protection and application-level mechanisms such as OAuth, JWT, API keys, gateways, and validation policies [14,21]. This approach is flexible, but its effectiveness depends on implementation quality and governance discipline.

The architectural design of both technologies serves different enterprise scenarios. SOAP remains relevant in industries that give priority to regulatory compliance, traceability, formal contracts, and transaction coordination, including banking, healthcare, and government applications [12,13,17,27]. REST is widely used in enterprise applications with microservices and cloud-native architectures because of its lightweight and loosely coupled design [16,17,26,29].

REST and SOAP are architecturally distinct. SOAP is an XML-based messaging protocol commonly used with formal service descriptions and optional WS-* specifications. These features support structured enterprise integration, but they also add complexity, payload size, and tighter coupling. REST is a stateless, resource-oriented architectural style that uses URIs, standard HTTP methods, and lightweight media types such as JSON. These properties support scalability, agility, and broad client compatibility, especially in cloud-native and web-facing systems.

Table 10. Key architectural differences between REST and SOAP.

Aspect	REST	SOAP	References
Design & Architecture	Lightweight, resource-oriented architectural style based on Web principles, HTTP methods, URIs, and REST constraints, widely adopted for scalable Web, cloud-native, and microservices systems.	Formal, XML-based, protocol-oriented, contract-driven messaging protocol designed for enterprise distributed systems and SOA/RPC environments with strict standards and predefined specifications.	[1,2,3,4,5,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,38]
Philosophy	Resource-oriented approach emphasizing simplicity, scalability, interoperability, flexibility, statelessness, and alignment with Web and Fielding principles.	Operation-oriented and document-centric approach emphasizing structured communication, strong contracts, governance, reliability, and standardized information exchange.	[1,2,3,4,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,35]
Data Format	Supports multiple lightweight formats including JSON, XML, HTML, YAML, and plain text, with JSON being the dominant format.	Exclusively uses XML with schemas, namespaces, envelopes, and structured message formatting.	[1,4,12,13,14,15,16,17,18,20,21,22,23,24,25,26,27,28,29,30,31,32,33]
Interface & Operations	Uses uniform interfaces and flexible API documentation such as OpenAPI/Swagger, focusing on resources identified by URIs and manipulated through standard HTTP methods.	Uses strict machine-readable contracts through WSDL/XSD to define operations, parameters, methods, and data types, focusing on RPC-style operation calls and predefined workflows.	[1,2,4,15,18,20,21,22,23,25,27,29,31]
State & Communication	Strictly stateless client-server communication primarily over HTTP/HTTPS using standardized Web communication patterns optimized for scalable and distributed systems.	Supports both stateless and stateful or session-coordinated communication, coordinated sessions, asynchronous messaging, distributed workflows, and enterprise-oriented communication patterns across multiple transport protocols including HTTP, SMTP, TCP, FTP, and JMS.	[1,2,12,13,14,15,16,17,18,19,21,23,24,25,27,29,31,32,33,35]
Security & Reliability	Primarily relies on HTTPS and token-based mechanisms such as OAuth, JWT, and API keys, while reliability and consistency are typically handled at the application layer.	Can be combined with WS-* specifications such as WS-Security, WS-ReliableMessaging, and WS-Transaction to support message-level protection, reliable delivery patterns, and transaction coordination in compatible environments.	[13,14,16,19,21,23,24,27,32,33,35]
Coupling & Standards	Loosely coupled and governed by REST architectural constraints such as statelessness, layered systems, cacheability, uniform interfaces, resource addressability, and HATEOAS.	Tightly coupled through rigid schemas, WSDL dependencies, strongly typed contracts, SOAP policies, UDDI, and WS-* standards.	[1,3,5,14,15,16,18,20,21,22,23,24,25,26,27,28,29]
Performance & Efficiency	Lightweight and efficient because of compact payloads, simpler parsing, reduced bandwidth usage, and minimal middleware requirements.	Heavyweight and resource-intensive because of verbose XML processing, large payloads, protocol overhead, and extensive middleware/tooling requirements.	[14,15,19,20,23,26,28,30,32,35]
Scalability & Compatibility	Highly scalable, cloud-native, and interoperable with modern Web ecosystems, distributed systems, containerized deployments, and microservices architectures.	More difficult to scale because of protocol overhead and dependence on traditional enterprise infrastructures, but offers strong platform and language interoperability for enterprise and legacy systems.	[1,17,18,20,26,29,35]
Discovery & Navigation	Uses URIs, hypermedia links (HATEOAS), and modern API repositories/documentation for dynamic resource discovery and navigation.	Uses fixed service endpoints, WSDL contracts, service registries, and historically UDDI for service discovery and orchestration.	[2,18,21,22,34,36,38]
Development & Maintenance	Easier to implement, maintain, deploy, extend, and integrate because of lightweight architecture and standardized Web technologies.	More complex to implement, maintain, and modify because of strict standards, XML configuration, specialized middleware, and enterprise tooling dependencies.	[14,15,20,23,26,32]
Primary Use Cases	Best suited for lightweight, scalable, Web-based, mobile, cloud-native, and microservices applications requiring agility and rapid development.	Best suited for enterprise systems, B2B integration, transactional workflows, regulated industries, asynchronous messaging, and security-sensitive applications requiring strict governance and reliability.	[1,19,21,26,28,30,33,35]

summarizes the main architectural dimensions for both technologies based on the findings from the selected studies.

4.2. Research Question 2: How Do REST and SOAP Compare in Terms of Performance and Scalability?

One of the most common findings in the reviewed literature is the relative performances of REST and SOAP. First, SOAP demands that every communication must involve the use of XML, with the message being wrapped in an envelope containing a header and a body. On its part, there is no such requirement on the data format for REST. JSON is the preferred choice in today’s environment [12,13,23,30]. There are many documented implications of such an approach in practice. Messages using the JSON format have been found to be lighter than those transmitted via SOAP. For instance, one paper revealed that REST messages were three to ten times more compact. In addition, another paper noted that REST payload sizes range from 380 bytes to 13,261 bytes while SOAP ranges from 3380 to 50,460 bytes [20,23,32]. Clearly, this implies lower bandwidth usage, reduced time taken for transfer and CPU processing. All these efficiencies imply the latency characteristic of REST [13,14,24,30].

REST response time and throughput: Direct empirical REST-SOAP comparisons in the selected corpus generally report lower latency and higher throughput for REST, but the magnitude of the difference is study-specific. Bajrami et al. [24] reported REST response time of approximately 0.12 s and SOAP response time of approximately 0.56 s in a simplified Python Flask/Zeep experiment. However, the original publication did not specify the versions of Python, Flask, Zeep, or other software components used in the experimental setup.

Soni and Ranga [14] reported REST latencies between 15.44 and 120.69 ms compared with SOAP latencies between 29.12 and 290.60 ms in their JAX-RS/JAX-WS benchmark. Jaiswal and Goel [16] reported approximately 150 ms for REST and 250 ms for SOAP under synthetic workload conditions, while Sloane [32] reported 30–70% smaller payloads and 50–70% faster processing for REST in a Salesforce integration context. These figures should be interpreted only in relation to the reported experimental conditions, not as universal enterprise estimates.

State management and horizontal scalability: REST imposes a stateless architectural constraint, meaning that each request should contain the information needed for processing and application session state should not be stored on the server between invocations [12,25,29,31]. This makes horizontal scaling easier because additional server nodes can be introduced without shared session coordination [13,21,23]. SOAP itself is not inherently stateful; SOAP services can be designed as stateless or stateful. In enterprise workflows, SOAP is often used with session-coordinated or transaction-oriented interactions when multi-step operations require consistency, rollback, or reliable messaging [13,15]. These designs can be useful in regulated back-office systems, but they add operational and scaling complexity.

Caching: Caching is provided natively within REST due to its support for semantics of HTTP protocol. In particular, this applies to GET request responses that can be cached and re-used using traditional HTTP intermediaries [13,18,22,23]. This improves performance without additional hardware as well as without increased latency on the server side [13,33]. Messages used by SOAP messaging protocol have stateful nature, context dependency, and use extensive amount of XML markup. As a result, such caching is not possible as response messages are not reusable without being aware of session state when messages were generated [13,21]. Several research works indicate that this caching inability is one of the reasons for poor throughput of SOAP [13,27,33].

Consumption of resources: Resource consumption data across the reviewed studies consistently favor REST, though the significance of this difference varies depending on the deployment context. In terms of CPU usage, benchmark studies report REST at approximately 50 percent utilization compared to around 70 percent for SOAP under equivalent loads [16,24,32]. This difference is primarily driven by the cost of XML parsing and schema validation that SOAP performs on every message, a processing overhead that scales directly with request volume [14,16,23,30]. Memory differentials are comparatively smaller. Soni and Ranga [14] observed SOAP consuming only one to two megabytes more memory than REST under concurrent load, suggesting that memory pressure alone is unlikely to be the deciding factor in most enterprise deployments. The practical significance of these resource gaps, however, differs by deployment environment. For resource-constrained environments such as mobile platforms, IoT devices, and serverless functions, the CPU and bandwidth savings offered by REST translate directly into reduced cost and improved responsiveness [19,25,29]. For server-side enterprise systems with dedicated infrastructure, the resource difference, while present, may be acceptable when weighed against the transactional capabilities that SOAP provides. This distinction between deployment contexts is not consistently drawn in the reviewed studies, which tend to report absolute resource figures without relating them to the operational requirements of the target environment.

SOAP can be combined with several WS-* specifications, including WS-Security, WS-ReliableMessaging, and WS-AtomicTransaction. When implemented and configured correctly, these specifications can provide message-level protection, reliable message delivery patterns, sequencing, and distributed transaction coordination. REST, on the other hand, does not prescribe a built-in reliability or transaction model. RESTful systems usually rely on HTTPS/TLS, OAuth, JSON Web Tokens, API gateways, idempotent operations, retries, event queues, compensating transactions, or saga patterns depending on system requirements. Therefore, SOAP may be preferred in regulated domains when formal standards-based reliability or transaction coordination is required, whereas REST can meet many enterprise security needs when supported by strong governance and implementation controls [27,32,33].

Deployment and operational contexts: The scalability attributes of both protocols are also influenced by the environment in which they are deployed. REST has evolved as the architectural style of choice for use with microservices, cloud-native technologies, and consumer-facing applications. Deployment techniques include Kubernetes, Docker, CI/CD, and API gateways [17,25,26,28,29,31]. SOAP is still predominantly used within traditional monolithic enterprise architectures and legacy application systems, where heavyweight middleware support, XML configurations, and contract enforcement continue to reign [12,17,26,28]. Research indicates REST’s superior suitability to mobile device environments as well as Internet of Things, where the high costs associated with SOAP’s large payloads due to constrained bandwidths and computing resources are a major concern [4,19,21,23,24,25,26,29,32]. One analytical source report high contemporary REST adoption among developers, but this figure is treated as contextual rather than a direct empirical estimate for all enterprise systems [31,32].

Across the direct empirical studies that compared REST and SOAP under reported workloads, REST generally performed better on latency, throughput, message size, and resource usage under normal benchmark or platform conditions. This should not be interpreted as a universal rule. The evidence is strongest for controlled benchmark settings and weaker for complex production enterprise deployments, where authentication, middleware, monitoring, governance, and legacy integration can alter the practical trade-off. SOAP incurs overhead, but the overhead may be acceptable where formal contracts and optional WS-* capabilities are required.

Table 11. Study Specific Quantitative Values Used in Performance Synthesis.

Study	Technology/Context	Reported Values	Condition/Interpretation
Soni and Ranga [14]	JAX-RS REST and JAX-WS SOAP services	REST 15.44–120.69 ms; SOAP 29.12–290.60 ms	Controlled benchmark; values are not pooled with other studies.
Bajrami et al. [24]	Python Flask REST and Zeep SOAP implementation	REST about 0.12 s; SOAP about 0.56 s	Simplified local experiment; useful for direction of effect only.
Jaiswal and Goel [16]	Synthetic workload comparison	REST about 150 ms; SOAP about 250 ms; REST 50–60 req/s and SOAP 30–40 req/s reported in the study summary	Synthetic workload; not production-representative.
Sloane [32]	Salesforce integration context	REST 30–70% smaller payloads and 50–70% faster processing	Platform-specific case/benchmark evidence.
Selected extracted ranges [20,23,32]	Payload size comparison	REST 380–13,261 bytes; SOAP 3380–50,460 bytes	Reported as extracted study-specific ranges, not meta-analysis.

Note: Values are measured or extracted study-level observations. They are not pooled estimates and should not be generalized beyond the reported conditions.

summarizes performance and scalability patterns, and

Table 12. Performance Comparison between REST and SOAP.

Performance Aspect	REST	SOAP	Tools/Methods	References
PERFORMANCE/RESPONSE TIME/LATENCY	Faster due to lightweight JSON payloads, reduced overhead, HTTP caching, and efficient request-response handling; commonly reports lower latency and response times (~0.1234 s, 15.44–120.69 ms, or ~150 ms).	Slower because of verbose XML envelopes, XML parsing, and higher computational overhead; commonly reports higher latency and response times (~0.5678 s, 29.12–290.60 ms, or ~250 ms).	Postman, AppPerfect Web Load Test, Benchmark Applications, Flask/Zeep Benchmarks, System.currentTimeMillis(), Benchmark & Monitoring Tools	[12,13,14,16,18,20,22,24,27,30,33,35]
THROUGHPUT & SCALABILITY	Higher throughput and scalability through statelessness, horizontal scaling, caching, load balancing, and cloud-native deployment (~50–60 req/s or ~150 req/s).	Lower throughput and scalability because of stateful or session-coordinated communication, tight coupling, monolithic deployment patterns, and higher processing overhead (~30–40 req/s or ~100 req/s).	Kubernetes, Docker, AWS EKS, Eureka, API Gateways, Load Balancers, Synthetic Workload Generators, CI/CD Platforms	[5,12,13,16,20,22,23,25,35,38]
PAYLOAD, PARSING & OVERHEAD	Lightweight JSON payloads (380–13,261 bytes) with faster parsing and lower protocol overhead.	Heavyweight XML envelopes with mandatory headers and larger payloads (3380–50,460 bytes), resulting in slower parsing and greater protocol overhead.	JSON.parse(), DOM Parser, XML Schema (XSD), Benchmark Applications, WSDL/XML Standards	[5,12,13,14,15,16,18,27,30,33]
RESOURCE & BANDWIDTH EFFICIENCY	Lower CPU, memory, storage, and bandwidth usage because of compact formats and lightweight communication (~50% CPU and ~200 MB memory).	Higher CPU, memory, storage, and bandwidth usage due to verbose XML structures and complex processing (~70% CPU and ~300 MB memory).	Runtime Analysis Tools, Monitoring Systems, Atlas Analytics, SIM-LP2M Architecture, Benchmark Measurement Tools	[13,14,16,18,20,22,25,30,32,38]
CACHING & STATELESSNESS	Stateless communication with strong HTTP caching support and cacheable GET responses, improving scalability and efficiency.	Stateful or session-coordinated communication with limited or no native caching support.	HTTP Caching, Standard Web Infrastructure, API Gateways	[5,13,21,23,25,27,29,31,33]
RELIABILITY & TRANSACTION PERFORMANCE	Relies mainly on HTTPS, OAuth, and application-level reliability mechanisms; optimized for agility and performance rather than strict transactional capabilities.	Can use WS-Security, WS-ReliableMessaging, reliable delivery patterns, sequencing, and WS-AtomicTransaction where the infrastructure supports these specifications.	WS-Security, WS-ReliableMessaging, OAuth2, JWT, SAML, WS-AtomicTransaction, HTTPS	[2,14,21,24,27,32]
DEPLOYMENT & OPERATIONAL EFFICIENCY	Optimized for CI/CD, microservices, containerization, cloud-native deployment, high-traffic systems, and low-latency distributed environments.	Commonly deployed in monolithic enterprise environments with heavier middleware, XML configurations, and lower operational flexibility.	Docker, Kubernetes, Jenkins, Spring Boot, RabbitMQ, Kafka, CI/CD Pipelines	[17,25,26,28,29,31,32,34]
MOBILE/CLOUD EFFICIENCY	Highly suitable for mobile, IoT, serverless, and cloud-native systems because of lightweight communication and efficient resource usage.	Less suitable for mobile, IoT, and constrained cloud environments because of larger payloads and higher processing overhead.	Mobile Frameworks, Cloud Platforms, Docker, Kubernetes, Serverless Environments	[4,19,21,23,25,29,32]

identifies the specific studies and conditions behind the numerical values cited in this section.

4.3. Research Question 3: How Do REST and SOAP Differ in Terms of Security and Reliability

Security and reliability are the areas in which SOAP-related standards can justify their additional complexity. Although the preceding sections show the performance and scalability advantages often associated with REST, the reviewed literature also indicates that SOAP remains relevant where formal contracts, message-level protection, reliable messaging patterns, and transaction coordination are required [14,21,25,27,37,38].

Security architecture: The reviewed literature mainly distinguishes REST and SOAP by where security controls are specified. SOAP can use WS-Security to carry encryption, digital signatures, and authentication tokens in the message header [14,27]. This can be useful when messages pass through intermediaries or when protection must not depend solely on the transport channel. REST commonly relies on HTTPS/TLS, OAuth 2.0, JWT, API keys, gateway policies, schema validation, and application-level access controls [14,21,24]. REST security is therefore not absent, but it is less prescribed by the architectural style and more dependent on implementation and governance quality.

Granularity of security control: Since SOAP offers message level security, it facilitates more granular control over the operations and messages with regard to encryption and signing. Individual segments can be selectively encrypted, enabling routers to route metadata information without access to the content data [27]. REST-based security controls tend to be more coarse-grained compared to the former. In order to get the same level of granular control, custom security controls have to be implemented using gateways or middleware, which can lead to variations in implementation consistency across service endpoints [14,27]. According to research studies focusing on governance in enterprises, this has been the main reason why regulated industries favor SOAP over other standards [25,37,38].

Standardization of authentication and authorization mechanisms: SOAP deployments can combine WS-Security with standards such as SAML in enterprise identity environments [14,27]. REST commonly uses OAuth 2.0, JWT, API keys, and gateway-based authorization. These REST mechanisms are widely used and scalable, but implementations can vary across organizations. The comparative issue is therefore not whether REST can be secure, but whether its security model is applied consistently across enterprise services [14,21,27,37].

Resistance to malformed data and attacks: SOAP services are often described through WSDL and XML Schema, which can support formal validation before message processing [2]. REST APIs can also validate input through OpenAI schemas, gateway rules, and application validators, but these controls depend on implementation discipline. The reviewed evidence does not include standardized penetration testing comparing REST and SOAP under equivalent attack conditions. For this reason, robustness and security conclusions are presented as standards-based and implementation-dependent, not as proof that one approach is always safer.

Error handling and reporting of errors: The SOAP messaging protocol has a predefined structure for the fault message which defines how errors are represented and categorized in all implementations [14,27]. This predictability has practical implications when developing mission-critical systems in the sense that downstream applications will need to know what kind of error messages to look out for to deal with failed operations. With REST error messages, which are based on the HTTP response codes, developers may not always adhere to the same guidelines and thus an error code such as 400, 422, or 500 can represent the same error [2,27].

Reliable messaging: SOAP services can use WS-Reliable Messaging where the infrastructure supports it [14,27,37,38]. This specification can support delivery assurances, duplicate detection, and ordering patterns independently of the underlying transport channel. REST services usually handle reliability through application-level mechanisms such as retries, message queues, idempotent operations, deduplication, monitoring, and compensating actions [2,22,31]. Where distributed transactions are involved, implementing equivalent reliability semantics in REST can require additional architectural design compared with SOAP-based WS-* environments [15,33,37,38].

Transactional integrity: To support distributed processes requiring atomicity across multiple compatible services, SOAP-based systems may use WS-Atomic Transaction to coordinate participants and rollback behavior [27]. REST does not provide an equivalent built-in distributed transaction specification. RESTful systems usually rely on compensating transactions, sagas, event-driven consistency, or application-specific rollback mechanisms [2,27]. Financial and healthcare integration studies often identify this difference as one reason why SOAP remains relevant where transaction coordination is mandatory [13,25,34,37,38].

Suitability to mission-critical enterprise environments: SOAP-related standards can make SOAP suitable for mission-critical enterprise contexts where failure has significant operational, legal, or financial consequences. Banking, military integration, telecom, and government back-office systems are cited in the literature as examples where SOAP may be selected because formal contracts and WS-* specifications can reduce implementation variability [14,18,21,25,32,37,38]. REST can also be used in these environments, but additional governance, testing, monitoring, and security controls are required to achieve comparable assurance [1,2,4,36].

Overall, the reviewed literature distinguishes REST and SOAP most clearly in security and reliability architecture. SOAP, when combined with WS-* specifications and compatible infrastructure, offers a standardized route to message-level security, reliable messaging patterns, formal fault handling, and transaction coordination. REST can also be secure and reliable, but these properties depend on implementation choices such as HTTPS, OAuth, JWT, API gateways, schema validation, retries, idempotency, monitoring, and compensating transactions. Therefore, the revised conclusion is not that SOAP is automatically more secure, but that SOAP has stronger standards-based support for certain high-assurance enterprise requirements.

Table 13. Descriptive evidence counts for selected security and reliability dimensions.

Dimension	REST Evidence Counts	SOAP Evidence Counts	Interpretation
Message-level security	1	8	SOAP is discussed more often because of WS-Security; this is standards-based evidence.
Formal service contracts	3	9	SOAP/WSDL is more frequently associated with strict contracts; REST documentation is often OpenAI-based.
Reliable messaging	2	7	SOAP is more frequently linked to WS-Reliable Messaging; REST relies on application/platform mechanisms.
Transaction coordination	2	6	SOAP is more frequently linked to WS-Atomic Transaction; REST uses compensating patterns.
Throughput/parsing efficiency	8	2	REST is more frequently associated with lightweight payloads and simpler parsing.
Agile/mobile/microservice fit	5	1	REST is more frequently associated with cloud-native and mobile contexts.

Note: Counts indicate how many selected studies explicitly discuss a dimension. They do not measure security effectiveness, robustness, or reliability in deployment.

reports descriptive evidence counts for these dimensions; the counts measure how often dimensions are discussed, not measured security effectiveness.

The findings related to security and reliability were synthesized according to the strength and type of evidence available in the selected studies.

Table 14. Security and Reliability Synthesis by Evidence Strength.

Dimension	REST Interpretation	SOAP Interpretation	Evidence Boundary
Security controls	Transport, identity, gateway, validation, and application controls	Message-level controls through WS-Security where implemented	Implementation-dependent vs. standards-based
Reliability	Retries, queues, idempotency, monitoring, compensating actions	WS-ReliableMessaging where supported	No direct equivalent fault-injection evidence
Transactions	Sagas, compensating transactions, event-driven consistency	WS-AtomicTransaction in compatible environments	Standards capability, not universal guarantee
Robustness	Depends on API validation and error handling	Can use WSDL/XML Schema and SOAP Fault structure	No universal empirical superiority established

Note: This table provides a standards-based and implementation-dependent interpretation. It does not establish universal empirical superiority for either approach.

presents the security and reliability synthesis, highlighting the interpretations of REST and SOAP, together with the corresponding evidence boundaries.

4.4. Research Question 4: In What Scenarios or Use Cases Is REST or SOAP More Appropriate in Enterprise Systems?

In the analysis of the 32 selected studies, the two approaches are aligned with different enterprise conditions. The selection of protocol or architectural style depends on operational risk, governance requirements, integration stability, and scalability needs. Direct empirical studies provide stronger evidence for performance-related choices, while use-case recommendations are supported by a combination of empirical, analytical, and contextual evidence [14,18,27,37,38].

Web and mobile applications for the general public: REST is favor by developers of client-side applications and mobile services. The light nature of its communication architecture, support for JSON, and conformity with the conventional HTTP protocol semantics make it very compatible with the dynamic and resource-limited environment of client-side technologies [1,4,5,27]. The stateless approach to handling requests eliminates the need to maintain any form of session state on the server side, making it easier to design and deploy APIs in multiple access channels [4,5]. On the other hand, SOAP requires a lot of bandwidth due to its complex envelope-based message format, which consumes valuable system resources that could be used elsewhere [14,18]. Several studies have identified this as one of the leading reasons for the widespread use of RESTful architecture in public facing web APIs. According to a particular study, about 75 to 90 percent of software developers currently opt for REST when developing new applications [31,32].

Microservices and cloud-native applications: In microservices architecture and cloud-native applications, REST has established itself as the favor of communication between services. The loose coupling nature of REST allows individual services to be independently built, deployed, and scaled. This is an architectural principle that underlies microservices, and SOAP’s WSDL-based contract enforcements violate this principle [1,5,14,23,27,36,38]. The statelessness of REST fits the cloud infrastructure model where compute nodes are ephemeral and horizontally scalable. REST also fits well into the cloud-native stack of container orchestration tools, CI/CD pipelines, and API gateways [25,26,29,31]. The stateful design and tight coupling nature of SOAP makes it difficult to fit into cloud-native infrastructures [14,23].

Banks and financial institutions: Financial services are one of the areas where SOAP can remain justified because of the formal assurance provided by WSDL contracts and WS-* specifications. WS-Security, WS-ReliableMessaging, and WS-AtomicTransaction can support message-level protection, reliable delivery patterns, sequencing, and distributed transaction coordination when implemented in compatible systems [13,25,34,37,38]. REST can also be used in financial services, but it normally requires strict governance, security gateways, monitoring, validation, idempotency, and compensating transaction design [1,2,4,18].

Government and public sector applications: There is an equivalent pattern of public-facing and back-office applications in government systems. The growing trend towards the use of REST-based architectures for citizen portals and low-criticality government services can be attributed to its flexible architecture that is also compatible with the current internet architecture [1,4,27]. In contrast, regulated back-office applications, data transfer across different agencies, and data exchange where specific legal guidelines dictate data format, always rely on SOAP. Service-level agreements and auditing capabilities are compulsory, not optional in this case 12,16,23,35,36]. Several researchers indirectly advocate the use of REST for public-facing applications and SOAP for back-office systems. Such a model could serve as a pragmatic solution to resolving conflicting demands in a single institution [14,27,37].

Integration of enterprise systems: When it comes to the integration of enterprise systems and especially when dealing with disparate technology platforms, the decision to be made rests upon the nature of integration contract in terms of stability. In the context of rapid adaptability and changeability of interfaces, REST provides enough flexibility to evolve and upgrade services independently of changing the whole contract between each client consuming that service [5,27,36]. In case of behavioral predictability being important, SOAP ensures a well-defined, machine-verifiable integration interface that both sides of communication can validate and test independently [14,23,37,38]. The legacy SOA-based environment is another particular situation. Obviously, in this case, SOAP is the way to go since it is seamlessly compatible with SOA infrastructure, enterprise middleware, as well as UDDI-based service discovery systems [14,18].

Transactional and SLA-driven services: Service-level agreements that require reliable delivery patterns, ordered processing, or formally defined fault tolerance are often associated with SOAP in the reviewed literature. WS-ReliableMessaging and WS-AtomicTransaction can provide standardized mechanisms for these requirements in compatible environments [15,33,37,38]. REST can support similar operational goals, but retry logic, idempotency, distributed tracing, message queues, and compensating actions must be designed at the application or platform level [2,22,31].

Mission-critical and high-risk operations: In contexts such as critical infrastructure, health records, telecom, and large enterprise integration, SOAP may be selected when formal contracts, defined fault structures, and WS-* standards are needed. This does not mean that REST cannot be used in high-risk systems. Rather, RESTful services in such settings require extensive validation, monitoring, security controls, idempotency design, and operational governance [1,2,36].

Rapid development and innovation: Where development efficiency and rapid iteration are key, RESTful services are commonly selected. This approach benefits from the lack of SOAP envelope schemas and the reduced dependency on the WS-* stack, allowing developers to create and deploy APIs faster than many SOAP equivalents [1,5,27]. REST tooling such as OpenAPI and Swagger further supports development and documentation processes [5,29,34]. SOAP’s strict contract approach and standards can be valuable in stable enterprise integration, but they may slow change in rapidly evolving systems [14,23].

There is no single protocol or architectural style that dominates all enterprise scenarios. REST is generally the better option for public web APIs, mobile applications, microservices, cloud-native architectures, and agile development environments where scalability, simplicity, and broad client compatibility are central. SOAP is a better fit when formal contracts, reliable messaging patterns, transaction coordination, legacy SOA compatibility, or strict governance requirements are more important. Many enterprises therefore use both approaches together, exposing RESTful interfaces for modern clients while retaining SOAP services in regulated or legacy back-end systems. The resulting enterprise use-case recommendations and their supporting evidence are summarized in

Table 15. Enterprise Use-Case Guidance and Evidence Basis.

Enterprise Scenario/Use Case	REST	SOAP	References
Public Web & Mobile Applications	Preferred due to lightweight communication, scalability, and ease of integration with web and mobile clients	Generally avoided due to heavier messaging and higher overhead	[1,4,5,14,18,27]
Microservices & Cloud Native Systems	Suitable for microservices, containerised deployments, and cloud platforms where loose coupling and scalability are required	Less suitable due to tight coupling and complex service contracts	[1,5,14,23,27,36]
Banking & Financial Systems	Can be used only with strict governance, security gateways, and extensive testing	Often preferred where WS-Security, reliable messaging patterns, and transaction coordination are required	[1,2,4,13,25,34,36,37,38]
Government & Public Sector Systems	Suitable for citizen-facing portals and less important services	Preferred for back-office, regulated, and mission-critical systems	[1,4,14,18,25,27,37,38]
Enterprise System-to-System Integration	Appropriate when flexibility and rapid evolution are required	Highly suitable due to formal WSDL contracts and predictable behavior	[5,14,23,27,36,37,38]
Transactional & SLA-Driven Services	Limited native support; requires additional reliability mechanisms	Can support reliable delivery patterns, ordering, and transaction coordination through WS-* specifications	[2,14,15,22,31,33,37]
Legacy Enterprise SOA Environments	Not ideal due to mismatch with existing SOA standards	Best fit due to compatibility with established SOA infrastructures	[14,18,23,37]
High-Risk/Mission-Critical Operations	Usable only with extensive testing, monitoring, and security layers	Often selected where formal fault handling, testing, and robustness are required	[1,2,21,32,36,37,38]
Rapid Development & Innovation	Strong choice due to simplicity, tooling, and faster development cycles	Slower to adapt due to rigid standards and contracts	[1,5,14,23,27]
Heterogeneous Service Composition	Suitable for lightweight and loosely coupled compositions	Better for complex compositions requiring strict coordination	[21,27,32,36,38]

Note: Use-case guidance is interpretive and context-sensitive. It should be read together with organizational requirements, implementation quality, and governance constraints.

.

5. Discussion

Figure 5 illustrates the structural contrast between the protocol driven, envelope-based model of SOAP and the resource oriented, URI-based architecture of REST. It highlights how SOAP relies on rigid WSDL contracts and XML encapsulation, whereas REST prioritizes a uniform interface and standard HTTP methods to achieve greater flexibility and scalability.

The revised synthesis supports a contextual interpretation of REST and SOAP rather than a universal ranking. REST and SOAP address overlapping integration problems, but they embody different engineering priorities. REST emphasizes resource orientation, statelessness, lightweight representations, and compatibility with web infrastructure. SOAP emphasizes structured XML messaging, formal service description, and compatibility with WS-* specifications used in some enterprise integration environments [16,27,29].

For RQ1, the architectural distinction between REST and SOAP is strongly supported as a descriptive finding. The evidence is not dependent on numerical benchmarking because it concerns protocol and architectural properties: REST is an architectural style, whereas SOAP is a messaging protocol. However, claims about the operational effect of those properties, such as easier scaling or stronger governance, require more caution because they depend on implementation and organisational context.

For RQ2, the direction of the performance evidence is consistent across the direct comparative studies. REST is generally reported as faster and lighter than SOAP within the selected benchmark, cloud-composition, synthetic workload, Python experiment, and Salesforce platform contexts [14,15,16,24,32]. The word generally is used here only within those reported conditions. The review does not establish a pooled effect size and does not claim that REST will outperform SOAP in every enterprise deployment. Middleware, authentication, message size, caching strategy, network topology, and transaction requirements may alter the practical outcome.

For RQ3, the evidence does not justify a blanket claim that SOAP is empirically more secure or robust than REST. The stronger conclusion supported by the selected literature is that SOAP, when combined with WS-* specifications and compatible infrastructure, provides a more standardized route to message-level protection, reliable messaging patterns, formal fault handling, and transaction coordination. REST can also be secure and reliable, but those properties depend on transport security, token management, API gateway policy, validation, idempotency, monitoring, and compensating transaction design. Because direct attack, fault, and recovery experiments are limited, the certainty for security and reliability remains low.

For RQ4, the use-case mapping should be interpreted as decision guidance rather than a prescription. REST is better aligned with public APIs, mobile clients, microservices, cloud-native systems, and rapid development when performance and adaptability are central. SOAP is better aligned with regulated, legacy, and transaction-oriented integration when formal contracts and standards-based reliability mechanisms are required. Hybrid deployment is a plausible enterprise pattern when REST interfaces expose or mediate SOAP back-end services, but the selected literature provides limited direct validation of long-term hybrid outcomes. Based on these findings, Figure 6 presents a provisional evidence-informed decision framework for selecting REST, SOAP, or a hybrid approach in enterprise contexts.

The most important limitation remains the heterogeneity of the evidence base. Some selected studies are direct REST-SOAP comparisons, whereas others are REST-only studies, SOAP-related studies, secondary reviews, analytical papers, or contextual technical sources. This review addresses the issue by explicitly separating measured values, extracted study-level observations, descriptive evidence counts, and interpretive summaries. Direct empirical comparisons are used for strong comparative performance claims. Contextual and secondary studies are used only to explain architectural or enterprise setting, not to independently establish superiority.

The keyword search strategy is also a limitation. Requiring REST and SOAP terms together strengthened retrieval of directly comparative literature, but it may have missed high-quality single-technology studies relevant to broader interpretation. For this reason, the paper should be understood as a structured literature review with systematic elements rather than an exhaustive systematic review of the entire REST and SOAP evidence base. A future update should use separate REST-focused, SOAP-focused, and hybrid-integration search streams, followed by record-level screening and publication of the complete extraction dataset.

Several research gaps remain. More production-representative benchmarking is needed under realistic middleware, authentication, concurrent user, and network conditions. Security and reliability research should include standardized penetration testing, malformed-input testing, fault injection, recovery measurement, and transaction-failure scenarios. More evidence is also needed on migration cost, hybrid REST-SOAP governance, and the relationship between REST, SOAP, GraphQL, gRPC, and event-driven architectures in enterprise systems.

Overall, the practical implication is that protocol selection should be based on operational requirements rather than preference. Organisations prioritizing high-throughput, web-facing, or cloud-native integration may reasonably start with REST, while organisations requiring formal contracts, message-level protection, reliable messaging, or transaction coordination may justify SOAP or hybrid designs. In all cases, security and reliability depend on implementation, testing, monitoring, and governance.

6. Conclusions

This structured literature review addressed four research questions concerning the architecture, performance and scalability, security and reliability, and domain-specific suitability of REST and SOAP in contemporary enterprise systems. The review synthesised 32 selected studies published between 2021 and 2026. Because the selected corpus contains mixed evidence roles, conclusions were bounded according to evidence strength: direct REST-SOAP empirical comparisons support comparative performance claims, while REST-only, SOAP-only, analytical, secondary, and contextual sources support interpretation.

Architecturally, SOAP is an XML-based messaging protocol commonly used with formal service descriptions such as WSDL and optional WS-* specifications. REST is a resource-oriented architectural style that emphasizes stateless interaction, uniform interfaces, standard HTTP methods, and lightweight media types such as JSON. These differences influence coupling, scalability, security architecture, reliability design, and integration governance.

For performance and scalability, direct comparative studies generally report REST as faster and lighter than SOAP within the reported benchmark, synthetic workload, cloud-composition, Python experiment, and Salesforce platform contexts. The reported advantages relate to lower response time, smaller payloads, simpler parsing, lower bandwidth usage, and easier horizontal scaling. These values are study-specific observations, not meta-analytic estimates, and should not be treated as fixed expectations for every enterprise deployment.

For security and reliability, SOAP can offer stronger standards-based support when WS-Security, WS-ReliableMessaging, WS-AtomicTransaction, and compatible infrastructure are implemented. These capabilities are not automatic properties of every SOAP implementation. REST relies more on transport security, identity standards, API gateways, validation, retries, idempotency, monitoring, and compensating transaction patterns. Therefore, REST security and reliability are implementation-dependent, while SOAP-based assurance is more specification-driven when the relevant standards are adopted.

For use-case suitability, REST is generally appropriate for public web APIs, mobile applications, microservices, cloud-native systems, and rapid development environments where scalability, simplicity, and broad client compatibility are central. SOAP is generally appropriate where formal contracts, reliable messaging patterns, transaction coordination, legacy SOA compatibility, or strict governance requirements are central. Hybrid REST-SOAP architectures remain relevant where modern client-facing services must coexist with regulated or legacy back-end systems.

The main contribution of the review is not a claim that one technology is universally superior. Its contribution is a decision-oriented synthesis that distinguishes measured values, extracted study-level observations, descriptive evidence counts, and interpretive summaries. The review also identifies evidence gaps, including limited production-representative performance testing, limited direct empirical security and fault-injection comparison, limited validation of hybrid deployment models, and limited evidence on newer alternatives such as GraphQL, gRPC, and event-driven integration.

The conclusions are constrained by the heterogeneity of the selected literature, the limited number of direct comparative studies, reliance on controlled benchmarks, limited production evidence, exclusion of grey literature, and uneven geographic and sectoral coverage. Future research should use broader search streams, publish complete extraction datasets, and conduct production-representative experiments that compare REST and SOAP under equivalent workload, security, reliability, and failure conditions. In conclusion, REST and SOAP should be evaluated according to enterprise context, not preference or habit. REST is well aligned with lightweight, scalable, web-facing and cloud-native integration. SOAP remains relevant where formal contracts and standards-based reliability or transaction coordination are required. Sound enterprise protocol selection should weigh performance, governance, interoperability, security, reliability, maintainability, and legacy constraints together.