We’re designing a supplier portal integration for our sourcing management system in Aras 12.0 and debating between REST and SOAP APIs. Our suppliers range from modern tech companies with REST-native systems to traditional manufacturers still using legacy SOAP-based ERP systems. I’m interested in hearing real-world experiences about REST performance advantages versus SOAP security standards, especially around testing tool compatibility and scalability considerations. What have others found works best for supplier connectivity when you have a mixed ecosystem?
Mixed-ecosystem integrations in Aras 12.0 surface this tradeoff clearly because the platform exposes both surfaces natively — the IOM SOAP API (long-standing) and the RESTful HTTP API introduced in later 11.x/12.x releases (verify exact endpoint availability in your 12.0 SP level).
Criteria Comparison
| Criteria | REST (HTTP API) | SOAP (IOM API) |
|---|---|---|
| Protocol overhead | Lightweight JSON payloads; lower bandwidth per call | XML envelope adds ~30–40% payload size; noticeable at volume |
| Security standards | TLS + OAuth/token-based; adequate for most modern portals | WS-Security, WS-ReliableMessaging, XML-Signature; stronger contract-level guarantees |
| Stateful transactions | Stateless by default; multi-step operations require orchestration logic | Native support for compound document submissions and transaction rollback via IOM |
| Error handling | HTTP status codes + JSON body; simpler to parse but less prescriptive | Structured SOAP faults with typed fault codes; easier to machine-process in legacy ERP pipelines |
| Testing tooling | Postman, Insomnia, curl — low friction for modern dev teams | SoapUI, ReadyAPI — mature WS-* testing; steeper setup for teams without XML tooling |
| Supplier-side compatibility | Native fit for REST-first systems (modern tech suppliers) | Direct fit for SAP ECC, Oracle EBS, older Ariba connectors via WSDL import |
| Aras-specific maturity | Newer surface; verify full ItemType coverage in your SP (verify in your version) | Fully mature; all ItemTypes, history, file vaulting accessible |
| Scalability | Stateless design simplifies horizontal load balancing | Session-affinity requirements can complicate scaling |
| Contract enforcement | No enforced schema on REST side without additional OpenAPI overlay | WSDL provides a machine-readable, versioned contract — useful when supplier change control is slow |
Practical Architecture Notes
For a mixed ecosystem, a gateway/adapter layer often outperforms a single-protocol mandate:
- Place an API gateway (MuleSoft, Azure API Management, or a lightweight NGINX proxy) in front of the Aras instance
- Expose a REST façade to modern suppliers; translate to IOM SOAP calls internally
- Legacy ERP suppliers connect via WSDL published from the gateway, preserving their existing integration tooling
This isolates Aras from protocol churn and lets you version supplier contracts independently.
On scalability: REST’s stateless model is genuinely easier to scale behind a load balancer — Aras SOAP sessions carry server-side state that complicates sticky-session management under high concurrent supplier submission volumes. If you anticipate batch PO acknowledgements or ASN floods, this matters.
On security: if suppliers operate under regulated frameworks (ITAR, CMMC), WS-Security’s message-level encryption and non-repudiation features carry weight that TLS-only REST doesn’t replicate without additional signing layers.
Ultimately, the right surface depends on context / your requirements — specifically, the ratio of legacy-to-modern suppliers, your internal team’s XML tooling familiarity, and whether transaction integrity or raw throughput is the dominant constraint.
This draft is based on general Aras Innovator knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
We went full REST for our supplier portal two years ago and haven’t looked back. The performance advantages are significant - REST is stateless so it scales horizontally much better, and JSON payloads are typically 30-40% smaller than equivalent XML. Our testing tools (Postman, REST Assured) work great with REST endpoints. The downside is that some older suppliers struggled with OAuth authentication compared to WS-Security they were used to in SOAP.
From a security standpoint, SOAP has some real advantages that people overlook. WS-Security provides message-level encryption and signing, which means your security travels with the message through intermediaries. REST relies on transport-level security (HTTPS), which is fine for point-to-point but breaks down in complex routing scenarios. For supplier portals handling sensitive procurement data, especially in regulated industries, SOAP security standards give you more granular control. That said, OAuth 2.0 with JWT tokens in REST can achieve similar security if implemented properly.
The legacy supplier support question is real. We have automotive suppliers whose ERP systems from 2008 only speak SOAP. Forcing them to REST would mean they’d need middleware or complete system upgrades, which they won’t do for one customer portal. We ended up implementing both - REST for modern suppliers and SOAP endpoints for legacy ones. It’s more maintenance overhead for us, but it maximized supplier adoption. The testing tool compatibility is actually fine for both - SoapUI handles both REST and SOAP well.
On scalability considerations, REST wins hands down for high-volume supplier portals. We handle 50,000+ API calls daily from 200+ suppliers, and REST’s stateless nature means we can load balance across multiple servers without session affinity. SOAP’s stateful operations require sticky sessions or shared state management, which limits horizontal scaling. Our response times averaged 120ms with REST vs 340ms with SOAP for equivalent operations. The caching story is also better with REST - you can use standard HTTP caching mechanisms.
One thing nobody’s mentioned is the developer experience. REST APIs are much easier to test and debug - you can hit endpoints directly from a browser for GET requests, the tooling is better, and the learning curve for suppliers’ developers is lower. With SOAP, you’re dealing with WSDL files, XML namespaces, and complex envelope structures. We’ve found supplier onboarding time is 40% faster with REST endpoints. However, SOAP’s strict contracts via WSDL do provide better interface versioning and validation.
Having implemented both approaches across multiple supplier portal projects, I can offer a comprehensive perspective on this decision.
REST Performance Advantages:
REST definitively outperforms SOAP in supplier portal scenarios for several reasons. The stateless nature means each request is independent, eliminating server-side session management overhead. In our benchmarks with Aras 12.0, REST endpoints averaged 85-150ms response times versus 250-400ms for equivalent SOAP operations. JSON serialization is faster than XML, and the smaller payload sizes reduce network transfer time - critical when suppliers are accessing your portal over variable internet connections. For bulk operations like retrieving RFQ lists or updating quote statuses, REST’s ability to leverage HTTP caching can reduce redundant data transfer by 60-70%.
SOAP Security Standards:
SOAP’s security model is more mature for enterprise B2B scenarios. WS-Security provides end-to-end message-level security with encryption and digital signatures that persist through message routing and intermediaries. This matters if your supplier portal architecture includes message brokers or ESB layers. SOAP also offers better support for complex authentication scenarios like SAML tokens for federated identity. However, modern REST implementations with OAuth 2.0, JWT tokens, and API gateways can achieve equivalent security with proper architecture. The key difference is that SOAP security is standardized and built-in, while REST security requires you to compose multiple standards.
Testing Tool Compatibility:
REST has a significant advantage here. Tools like Postman, Swagger UI, and REST Assured provide excellent testing experiences with minimal setup. Suppliers can test REST endpoints directly from browsers for simple GET requests, which dramatically reduces support burden. SOAP requires specialized tools like SoapUI and understanding of WSDL files. However, for automated testing in CI/CD pipelines, both work well - we use SoapUI for SOAP and REST Assured for REST with equal effectiveness. The difference is in ad-hoc testing and supplier onboarding.
Legacy Supplier Support:
This is where you need pragmatic thinking. If 40% of your supplier base runs legacy ERP systems (SAP R/3, Oracle E-Business Suite 11i, custom AS/400 systems), they likely have existing SOAP integration capabilities but no REST infrastructure. Forcing them to REST means they’ll need middleware or system upgrades, creating adoption barriers. We’ve found the optimal approach is a dual-stack implementation: REST as the primary API for modern suppliers, with SOAP endpoints maintained for legacy systems. Use an API gateway to route to appropriate backends, keeping your core Aras integration layer protocol-agnostic.
Scalability Considerations:
For supplier portals expecting growth, REST’s scalability advantages are substantial. Horizontal scaling is trivial with stateless REST - add more application servers behind a load balancer without session affinity concerns. We scaled from 50 to 300 suppliers without architectural changes, just additional compute resources. SOAP’s stateful operations complicate this, requiring distributed session management or sticky sessions that limit load balancing effectiveness. REST also integrates better with cloud-native architectures - we deployed our REST API to Kubernetes with auto-scaling, something much harder with SOAP services.
Practical Recommendation:
For a mixed supplier ecosystem, implement a hybrid approach:
- Build your core integration layer protocol-agnostic (facade pattern)
- Expose REST APIs as the primary interface for modern suppliers
- Maintain SOAP endpoints for legacy suppliers (can be auto-generated from REST definitions)
- Use an API gateway (Kong, Apigee, AWS API Gateway) to handle routing, security, and transformation
- Document both APIs thoroughly but promote REST in onboarding materials
- Plan to sunset SOAP endpoints over a 3-5 year timeline as suppliers modernize
This gives you REST’s performance and scalability benefits while maintaining legacy supplier support without forcing costly upgrades on your partners.