SOAP vs REST—Which is Best for Integrating with N‑central?

As part of my work as a Head Nerd, I have the pleasure of meeting with MSPs from all over the world. About a month ago, I was speaking with four technicians from a global MSP based out of California. They were very technically savvy, had a deep understanding of PowerShell, and had a huge emphasis on automation in their business. As part of their vetting of the N‑central Platform, they had two key questions:

1. Did it have the required APIs so they could pull the necessary asset information as part of their Inventory process?
2. Were they able to pull monitoring in a failed state so they could consume that data and use it with their Microsoft Azure API gateway (along with other Data inputs from MSP tools they were using)?

Both of these can be easily done in N‑central by using the DeviceAssetinfoExportwithSettings API, and the ActiveIssuesList. I’ve included a PowerShell code example at the bottom of this article.

So, in this article I want to break down some of the misconceptions around Simple Object Access Protocol (SOAP) and explain what REpresentational State Transfer (REST) APIs are, how they both have their Pros and their Cons, and how they relate to the N‑central platform.

What are REST and SOAP?

REST, which stands for REpresentational State Transfer, is an architectural style and set of principles for designing networked applications and APIs (Application Programming Interfaces) that use HTTP (Hypertext Transfer Protocol) as the underlying communication protocol.

Meanwhile, SOAP or Simple Object Access Protocol is a protocol specification for exchanging structured information in web services. It provides a way for applications and systems using different programming languages to communicate with each other over a network. SOAP is based on XML (eXtensible Markup Language) and typically uses HTTP or other protocols for transporting messages between client and server.

Related Product

N‑central

Manage large networks or scale IT operations with RMM made for growing service providers.

Más información

Is SOAP a legacy technology?

Now, let’s start with the question I get from time to time, that prompted this blog. Are SOAP APIs legacy? In short no, not even close. I’ll explain some of the benefits and some of drawbacks.

In terms of N‑central architecture, N‑central uses an Enterprise Linux distro with a PostgreSQL database. SOAP was the only standard in APIs since APIs were created as a concept over 20+ years ago. That being said, interfacing with SOAP APIs are not as easy as REST. As a result, many believe that SOAP APIs are outdated technology—Wrong!

What are the benefits of SOAP APIs?

SOAP has some major benefits over REST APIs, which I’ve detailed below:

1. Robustness: SOAP provides a standardized protocol for exchanging structured information and has built-in error handling and fault tolerance mechanisms. It supports ACID (Atomicity, Consistency, Isolation, Durability) transactions and ensures reliable message delivery.
2. Formality and Contracts: SOAP APIs require a formal contract defined using Web Services Description Language (WSDL). This contract provides a detailed description of the API, including the operations, data types, message formats, and transport protocols. The contract facilitates easier integration and reduces ambiguity between different systems.
3. Security: SOAP supports various security standards, such as WS-Security, which provides message-level security, encryption, and digital signatures. These features are essential for applications handling sensitive data or requiring stringent security measures.
4. Compatibility: SOAP APIs are language-agnostic and can be used with a wide range of programming languages and platforms. The extensive support for different protocols like HTTP, SMTP, TCP/IP, and others allows SOAP to work across heterogeneous environments.
5. Advanced Features: SOAP offers advanced features like WS-AtomicTransaction for distributed transactions, WS-ReliableMessaging for reliable delivery, and WS-Policy for defining service policies. These features make SOAP suitable for enterprise-level applications with complex requirements.

What are the Drawbacks of SOAP APIs?

It’s also important to note that SOAP APIs also come with certain drawbacks. These include:

1. Complexity: SOAP APIs tend to be more complex compared to other web service architectures like REST. SOAP messages are typically XML-based and require additional parsing and processing overhead. The complexity can make it more challenging for developers to understand and implement SOAP-based services.
2. Overhead: SOAP messages are verbose and contain a lot of metadata, which adds to the payload size. This can result in larger message sizes and increased bandwidth usage compared to more lightweight alternatives like REST, especially in bandwidth-constrained environments or with large-scale API usage.
3. Performance: Due to the XML-based nature of SOAP, processing SOAP messages can be computationally expensive. The additional parsing, validation, and transformation operations required can impact the performance and response times of SOAP-based APIs, especially in high-throughput scenarios.
4. Limited Browser Support: SOAP APIs are not as widely supported by web browsers compared to REST APIs. SOAP relies on XML and requires more advanced parsing capabilities, which may not be fully supported or easily implemented in client-side JavaScript applications.
5. Lack of Human Readability: SOAP messages are not designed to be easily readable or understandable by humans. The XML-based structure and metadata make it less straightforward for developers to manually inspect or debug SOAP messages, making troubleshooting more challenging.

What are the benefits of REST APIs?

Now let’s look at REST APIs. There are some key benefits of a REST API, these include:

1. Simplicity and Ease of Use: REST APIs are simpler and easier to understand and implement compared to SOAP APIs. REST leverages standard HTTP methods like GET, POST, PUT, and DELETE, which are widely understood and supported. The simplicity of REST makes it more accessible to developers and reduces the learning curve.
2. Lightweight Communication: REST APIs typically use lightweight data formats like JSON (JavaScript Object Notation) for data representation, which results in smaller message sizes and more efficient data transfer. This makes REST APIs faster and more suitable for bandwidth-constrained environments or mobile applications.
3. Scalability and Performance: The stateless nature of REST APIs allows for horizontal scaling and better performance under heavy loads. The absence of server-side session management makes REST APIs more scalable, as they don’t rely on storing client state. This scalability ensures better responsiveness and faster processing.
4. Flexibility and Compatibility: REST APIs are flexible and can be consumed by a wide range of clients, including web browsers, mobile devices, and other systems. They are not tied to a specific technology stack or programming language, enabling interoperability between different platforms. REST’s compatibility with existing web infrastructure and standards simplifies integration with other web services.
5. Cacheability and Caching: REST APIs leverage the HTTP protocol’s caching mechanisms, allowing responses to be cached by clients or intermediary systems. Caching can significantly improve performance by reducing the need for redundant requests to the server. This benefit is particularly advantageous for frequently accessed resources or static content.

SOAP vs REST: Which is Right for You?

While SOAP APIs have been widely used in enterprise scenarios where formal contracts, security, and reliability are critical, the growing popularity of more lightweight and simpler alternatives like REST has led to their decreased adoption in many modern web development scenarios.

There are some modest drawbacks to the REST API, especially since REST APIs often can lead to over-fetching or under-fetching of data. Fine-grained control over the data retrieval and manipulation is sometimes limited in RESTful architectures.

Ultimately, the choice between SOAP and REST depends on factors such as the specific requirements of the application, existing infrastructure, and the level of formality and complexity needed in the API communication.

…and who most importantly, needs to use the N‑central API?

Typically, RMM technicians and end-users are not experienced enterprise web developers, they are systems administrators and technicians, so there is an increasing demand to convert the N‑central (or at least build some parity) in to REST APIs.

What is N‑able working on when it comes to REST APIs? 

It’s an exciting time!

If you’re not already aware, N‑able has undertaken significant research around the N‑central REST API modernization. We have conducted partner interviews and we fully understand where we need to go with our REST APIs based on our partner feedback.

Unfortunately, as much as I would like to outline what those APIs are going to be that is currently inflight so I am unable to at this time. But if you are interested about it post an article on our N‑able slack, or on our reddit page at r/Nable and start a thread there.

I would love to hear your ideas for REST APIs in N‑central.

PowerShell SOAP Call Code Example

Export customer list and available regtoken:

$serverHost = "INSERTServerFQDN"
$JWT="INSERTJWT“
$ExportFile = "C:\temp\TEST.csv"
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$NWSNameSpace = "NAble" + ([guid]::NewGuid()).ToString().Substring(25)
$KeyPairType = "$NWSNameSpace.EiKeyValue"
$bindingURL = "https://" + $serverHost + "/dms2/services2/ServerEI2?wsdl"
$nws = New-Webserviceproxy $bindingURL -Namespace ($NWSNameSpace)
$KeyPair = New-Object -TypeName $KeyPairType
$KeyPair.Key = 'listSOs'
$KeyPair.Value = "False"
$CustomerList = $nws.customerList("", $JWT, $KeyPair) 
 $Customers = ForEach ($Entity in $CustomerList) {    
    $CustomerAssetInfo = @{}    
    ForEach ($item in $Entity.items) { $CustomerAssetInfo[$item.key] = $item.Value }    
    [PSCustomObject]@{
        ID                = $CustomerAssetInfo["customer.customerid"]
        Name              = $CustomerAssetInfo["customer.customername"]
        parentID          = $CustomerAssetInfo["customer.parentid"]
        RegistrationToken = $CustomerAssetInfo["customer.registrationtoken"]
    }
}
$Customers | Export-Csv -Path $ExportFile -NoTypeInformation

Jason Murphy is the Head Nerd for N‑central and Efficiency at N‑able. You can follow him on reddit on r/nable or LinkedIn at ncentral_nerd.

Legal disclaimer:

This content may contain forward-looking statements regarding future product plans and development efforts. N‑able considers various features and functionality prior to any final generally available release.  Information regarding future features and functionality is not and should not be interpreted as a commitment from N‑able that it will deliver any specific feature or functionality in the future or, if it delivers such feature or functionality, any time frame when that feature or functionality will be delivered.  All information is based upon current product interests, and product plans and priorities can change at any time. N‑able undertakes no obligation to update any forward-looking statements regarding future product plans and development efforts if product plans or priorities change.