top of page

SOAP vs REST

Updated: Mar 13

This article is about the difference between SOAP and REST APIs and how this is relevant to integrating to the Cx Housing Management system, whether that be integration you are already using, or for future integration projects. We'll start with discussing the differences between the two types, and finish with what this means to you.


SOAP (Simple Object Access Protocol) and REST (Representational State Transfer) are two types of web services that allow applications to communicate with each other over the internet.


SOAP API


SOAP is a messaging protocol that uses XML to exchange information between applications. It has been around since the late 1990s and is widely used in enterprise applications. SOAP uses a standardized format for messages, which makes it easy to create interoperable services that can be used across different platforms and languages. This means that SOAP services can be used by applications running on different operating systems, eg Windows, Linux, and macOS, and can be written in different programming languages, such as Java, .NET, and PHP.


One of the main advantages of SOAP is that it is highly standardized, which makes it easier to create interoperable services that can be used across different platforms and languages. This is important in enterprise applications where there may be many different systems and applications that need to work together.


Additionally, SOAP provides a standardized way of handling errors, which makes it easier to debug problems and troubleshoot issues.

Another advantage of SOAP is that it provides more advanced security features than REST. SOAP supports encryption and digital signatures, which means that data can be transmitted securely between applications. This is important in applications where sensitive data, such as financial data or personal information, is being transmitted between applications.


However, there are also some disadvantages to using SOAP. One of the main disadvantages is that it is more complex than REST, which means that it can be more difficult to develop and maintain SOAP services.


Additionally, SOAP messages are typically larger than REST messages, which can impact performance in applications with high volumes of data. Finally, SOAP services may not be as flexible as REST services, which can make it more difficult to customize them to meet specific business needs.


One of the most useful aspects of SOAP is the Web Services Description Language (WSDL). This is a file that’s associated with SOAP. It provides a definition of how the web service works, so that when you create a reference to it, your development IDE can completely automate the process. So, the difficulty of using SOAP depends to a large degree on the language you use.


REST API


REST is a web service architecture that uses HTTP to exchange data between applications. It is simpler than SOAP and uses a more lightweight data format, such as JSON or XML. REST services are designed to be more flexible and scalable than SOAP services and are often used in mobile applications and other web-based applications that need to interact with web services. Unlike SOAP, REST does not use a standardized format for messages, which means that REST services can be more flexible and can be customized to meet specific business needs.


One of the main advantages of REST is that it is simpler and more lightweight than SOAP, which makes it easier to develop and maintain REST services. REST is also more flexible than SOAP, which means that it can be customized to meet specific business needs. Additionally, REST messages are typically smaller than SOAP messages, which can improve performance in applications with high volumes of data.


However, there are also some disadvantages to using REST. One of the main disadvantages is that it does not provide the same level of standardization and security as SOAP. This can be a concern in applications where sensitive data is being transmitted between applications.


Why is this relevant?


The Cx Housing Management System has been using SOAP web services for the past 10 years, and the number of methods, or 'things' you can do has evolved with each release. Web services integration is most often used with repairs systems where jobs are pushed out and then status updates, variations, and invoices are pushed back to Cx.


Civica, the vendor of Cx, is due to be developing REST APIs at some point in the near future. It has advised it will continue to include and support SOAP APIs in future releases which is extremely important given the number of sites that have developed integration for critical business processes.


That said... maintenance of multiple code bases or multiple parts of an application which do similar things carries a large overhead. Both sets of code need to be stored, maintained and managed. Where changes or new functionality occurs, both sets will need to be QA'd; both sets need to be supported, patched and fixed should issues arise. Both sets need to be managed throughout the release process. So whilst at this time it may seem like both SOAP and REST are due to be supported... we might find at some point one is favoured over the other and new methods don't get added to both.


That said, with a suitably skilled web development team, both SOAP and REST APIs could be employed in the same application if this does turn out to be the case.


So what should you do?


The short answer, and consultant favourite...is it depends, and it really depends on your specific project, what it needs to deliver and what are the important design factors eg. functionality, maintenance, security, speed and skill sets to mention but a few. There's no sign of either disappearing any time soon, and if your development teams prefer one over another then as long as it delivers the outcome, so be it. As with anything though, don't go all in without testing first. Engage in a small proof of concept to prove the solution will work, and will deliver the needs of the business, before committing to a much bigger development time and cost.

Comments


© 2025 by iStride Ltd.

bottom of page