IntegrationArchitect (Hardest)restsoapapi-strategy
Design REST vs SOAP API strategy for enterprise integrations
Real World Scenario
A 15-year enterprise has 40 SOAP integrations from legacy ERP while new mobile apps prefer REST. Leadership wants a unified API strategy without big-bang migration.
Expected Answer
• Default new integrations to REST Composite and Bulk API 2.0 for JSON-native consumers
• Maintain SOAP for stable legacy until replacement ROI justifies migration
• API gateway or MuleSoft layer abstracting Salesforce API choice from consumers
• Publish OpenAPI specs for REST endpoints; WSDL versioning for remaining SOAP
• OAuth 2.0 JWT bearer for server-to-server; avoid long-lived passwords
• Central integration catalog documenting owner, pattern, volume, and SLA per interface
• Deprecation policy with minimum 18-month notice for SOAP consumers
Follow-Up Questions & Answers
Click to expand — each follow-up includes a direct, interview-ready answer
Direct answer: Default new integrations to REST Composite and Bulk API 2.0 for JSON-native consumers Also consider: Maintain SOAP for stable legacy until replacement ROI justifies migration In practice: API gateway or MuleSoft layer abstracting Salesforce API choice from consumers Document the decision in an ADR and align with enterprise standards.
Architect Perspective
REST-first for new work does not mean SOAP rip-and-replace—architects manage portfolio lifecycle with explicit migration waves.